CVE-2026-42945 NGINX Rift: 18 Jahre alter Rewrite-Heap-Overflow, CVSS 9.2, ausgenutzt

Diese Woche in unserer InSEKurity of the Week-Serie: ein Fehler, der seit achtzehn Jahren unbemerkt im meistverbreiteten Webserver der Welt mitfährt. CVE-2026-42945, Spitzname „NGINX Rift”, ist ein Heap-basierter Buffer Overflow im ngx_http_rewrite_module. Ein entfernter, unauthentifizierter Angreifer kann eine einzige präparierte HTTP-Anfrage senden, die NGINX dazu bringt, einen Zielpuffer nach einer Escaping-Regel zu berechnen und ihn dann mit einer anderen, expansiveren Regel zu beschreiben — sodass Zeichen wie +, % und & sich verdreifachen und der Schreibvorgang über das Ende der Allokation hinausläuft. Die Korruption ist vom Angreifer geformt, weil die überlaufenden Bytes direkt aus der Request-URI stammen. Für die überwältigende Mehrheit der verwundbaren Konfigurationen ist das praktische Ergebnis ein zuverlässiger, reproduzierbarer Absturz des Worker-Prozesses (DoS); auf Hosts, bei denen ASLR deaktiviert ist, sind sich mehrere Analysen einig, dass es zu Remote Code Execution wird. CVSS 4.0 9.2 (Critical). Die Schwachstelle wurde von depthfirst am 2026-05-13 offengelegt, mit einem funktionierenden PoC, der noch am selben Tag auf GitHub veröffentlicht wurde, und die Canary-Systeme von VulnCheck meldeten bis zum 2026-05-16 eine Ausnutzung in freier Wildbahn — drei Tage später. Mit rund 5,7 Millionen aus dem Internet erreichbaren NGINX-Servern auf einem potenziell verwundbaren Build ist dies der „Jetzt-patchen”-Fehler der Woche für jeden, der NGINX auch nur in der Nähe einer rewrite-Regel betreibt.

📋 Zusammenfassung

CVE-ID: CVE-2026-42945 („NGINX Rift”)
CVSS-4.0-Score: 9.2 (Critical)
CVSS-4.0-Vektor: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CVSS-3.1-Score: 8.1 (High) — CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE: CWE-122 (Heap-based Buffer Overflow)
Betroffene Software: NGINX Open Source 0.6.27 bis 1.30.0; NGINX Plus R32 bis R36; F5-Produkte, die die Engine bündeln — NGINX Ingress Controller, F5 WAF for NGINX, NGINX Instance Manager, NGINX Gateway Fabric, NGINX App Protect DoS
Konfigurationsvoraussetzung: eine rewrite-Direktive, deren Ersetzung ein ? enthält, eine unbenannte PCRE-Capture-Gruppe ($1, $2, …) verwendet und der eine weitere rewrite-, if- oder set-Direktive folgt
Angriffsvektor: Netzwerk — eine einzige präparierte HTTP-Anfrage an einen beliebigen verwundbaren Virtual Host
Authentifizierung erforderlich: Nein — vollständig pre-auth
Benutzerinteraktion: Keine
Auswirkung: Heap Buffer Overflow im NGINX-Worker. Praktisch: zuverlässiger Denial of Service (Worker-Absturz/Neustart) für praktisch alle verwundbaren Konfigurationen; mögliche unauthentifizierte Remote Code Execution, wenn ASLR deaktiviert ist
Patch-Status: Behoben in NGINX Open Source 1.30.1 und 1.31.0; NGINX Plus R32 P6, R36 P4 und 37.0.0. Distro-Pakete von AlmaLinux, Debian und Ubuntu.
Veröffentlicht: NVD-Eintrag / öffentliche Offenlegung 2026-05-13; F5-Advisory K000161019 (2026-05-14)
Exploitation-Status: Öffentlicher PoC auf GitHub seit 2026-05-13; Ausnutzungsversuche von VulnCheck-Canaries am 2026-05-16 gemeldet, öffentlich bestätigt 2026-05-18
CISA KEV: Nicht gelistet zum Zeitpunkt der Erstellung

🧩 Was ist NGINX (und das Rewrite-Modul)?

NGINX ist mit großem Abstand der meistverbreitete Webserver und Reverse Proxy im Internet. Er steht vor rund einem Drittel aller Websites, terminiert TLS für einen enormen Anteil des weltweiten HTTPS-Verkehrs und läuft als Ingress-Data-Plane in einem riesigen Teil aller Kubernetes-Cluster (NGINX Ingress Controller). NGINX gibt es in zwei Editionen, die denselben Kern teilen: NGINX Open Source (der kostenlose, allgegenwärtige Build, der in praktisch jeder Linux-Distribution enthalten ist) und NGINX Plus (die kommerzielle Edition von F5 mit zusätzlichen Load-Balancing-, Observability- und API-Management-Funktionen). In beiden Fällen ist der Request-Handling-Kern — einschließlich des Moduls im Zentrum dieses Fehlers — derselbe Code.

Das ngx_http_rewrite_module ist eines der meistgenutzten Module in realen NGINX-Konfigurationen. Es implementiert die Direktiven rewrite, if, set, return und break, zu denen Administratoren ständig greifen: Umschreiben alter URLs auf neue, Normalisieren von Pfaden, Entfernen oder Neuaufbauen von Query-Strings, bedingtes Routing und Bewahren des ursprünglichen Request-Pfads für einen Upstream. Wer jemals rewrite ^/old/(.*)$ /new/$1 ...; geschrieben hat, hat genau den Codepfad benutzt, in dem „NGINX Rift” lebt.

Typische Anwendungsfälle (d. h. wer exponiert ist)

Reverse Proxies / API-Gateways, die eingehende Pfade umschreiben, bevor sie an Upstreams weiterleiten.
Migration alter URLs — permanente/temporäre Redirects und interne Rewrites, die erfasste Pfadsegmente bewahren.
Query-String-Manipulation — Regeln, die ?key=value-Argumente anhängen, entfernen oder neu aufbauen (hier lebt der durch ? ausgelöste Codepfad).
Multi-Tenant-Hosting — per-vhost Rewrite-Regeln, die aus Templates generiert werden, wobei sich ein riskantes Muster über Tausende von Sites verbreitet.
Kubernetes Ingress — der NGINX Ingress Controller rendert rewrite-target-Annotationen genau in die hier betroffenen Direktiven.
CDN-/WAF-Edge-Tiers — NGINX-basierte Edge-Nodes, die Requests vor dem Origin normalisieren.

Die exponierte Population ist tatsächlich von Internet-Größenordnung. Öffentliche Scan-Daten setzen rund 5,7 Millionen aus dem Internet erreichbare NGINX-Server auf einer potenziell verwundbaren Version an. Die wirklich ausnutzbare Teilmenge ist kleiner — sie erfordert das spezifische Rewrite-Muster unten — aber dieses Muster ist häufig genug und Template-Konfiguration weit genug verbreitet, dass niemand annehmen sollte, außerhalb des Geltungsbereichs zu sein, ohne nachzuprüfen.

🔬 Technische Analyse

Beschreibung der Schwachstelle

CVE-2026-42945 ist ein Heap-basierter Buffer Overflow (CWE-122) in der Behandlung des Ersetzungsstrings einer rewrite-Direktive durch das NGINX-Rewrite-Modul. NGINX baut die umgeschriebene URI in zwei getrennten Durchläufen auf: einem Längen-Durchlauf, der berechnet, wie groß der Zielpuffer sein muss, und einem Kopier-Durchlauf, der die Bytes tatsächlich schreibt. Der Fehler ist ein Zustands-Mismatch zwischen diesen beiden Durchläufen: Unter einer bestimmten (und häufigen) Direktiven-Anordnung zählt der Längen-Durchlauf die Größe zu niedrig, die Allokation ist daher zu klein, und der Kopier-Durchlauf schreibt über deren Ende hinaus. Da die überlaufenden Bytes direkt aus der Request-URI des Angreifers abgeleitet werden, ist die Heap-Korruption vom Angreifer geformt, nicht zufällig — und genau das trennt „garantierter Absturz” von „mögliche Code-Ausführung”.

Root-Cause-Analyse

Ein ? in der Rewrite-Ersetzung kippt ein internes is_args-Flag. Wenn der Ersetzungsstring einer rewrite-Direktive ein Fragezeichen enthält, vermerkt NGINX, dass alles danach ein Query-String ist, und setzt den internen is_args-Zustand auf 1. Entscheidend: Dieser Zustand bleibt für den Rest der Rewrite-Phase kleben, wenn der Direktive eine weitere rewrite-, if- oder set-Direktive folgt.
Der Längen-Durchlauf nutzt eine frische Sub-Engine, in der is_args == 0 ist. Er liefert die rohe, nicht-escapete Länge jeder unbenannten PCRE-Capture ($1, $2, …). Kein Escaping wird berücksichtigt, also ist die berechnete Größe die „kleine” Zahl.
Der Kopier-Durchlauf nutzt die Haupt-Engine, in der is_args == 1 ist. Dies führt dazu, dass ngx_escape_uri() mit der NGX_ESCAPE_ARGS-Tabelle aufgerufen wird, während die erfasste Gruppe ausgegeben wird. Unter dieser Tabelle expandieren Zeichen, die in einem Pfad zulässig sind, in einem Query-String aber prozent-kodiert werden müssen — insbesondere +, % und & — jeweils von 1 Byte auf 3 Bytes (%2B, %25, %26).
Kleine Allokation, großer Schreibvorgang. Der Zielpuffer wurde für die nicht-escapete Capture dimensioniert (Schritt 2), aber der Kopier-Durchlauf schreibt die escapete, expandierte Capture (Schritt 3). Jedes +, % oder &, das der Angreifer in die Capture-Gruppe stopft, fügt dem Schreibvorgang zwei zusätzliche Bytes hinzu, der Allokation aber null. Der Schreibvorgang läuft über das Ende des Heap-Chunks hinaus.
Nur unbenannte Captures. Der Mismatch hängt am Codepfad für unbenannte Captures ($1, $2, …). Benannte Captures ((?<name>...)) nehmen einen anderen, korrekt dimensionierten Pfad — das ist die Grundlage für den offiziellen Workaround.
Achtzehn Jahre Dornröschenschlaf. Die fehlerhafte Längen-/Kopier-Trennung ist seit etwa 2008 (NGINX 0.6.27) im ngx_http_rewrite_module, wodurch jedes Release bis einschließlich 1.30.0 verwundbar ist. Sie überlebte so lange, weil der Trigger eine präzise Kombination erfordert (unbenannte Capture + ? in der Ersetzung + ein folgendes rewrite/if/set), die in der Produktion häufig ist, von Fuzzern auf Default-Konfigurationen aber selten getroffen wird.

Verwundbares Konfigurationsmuster

Der Fehler tritt nur auf, wenn die Konfiguration die Trigger-Form trifft. Ein minimaler verwundbarer Block:

# VERWUNDBAR: unbenannte Capture ($1) + '?' in der Ersetzung +
# eine folgende 'set'-Direktive, die die Rewrite-Phase referenziert.
location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;   # '?' setzt is_args
    set $original_endpoint $1;                      # folgende Direktive
    proxy_pass http://backend;
}

# SICHER: benannte Capture nimmt einen anderen, korrekt
# dimensionierten Codepfad.
location ~ ^/api/(?<rest>.*)$ {
    rewrite ^/api/(?<rest>.*)$ /internal?migrated=true;
    set $original_endpoint $rest;
    proxy_pass http://backend;
}

Angriffsvektor

Der End-to-End-Pfad ist trivial: einen verwundbaren Virtual Host finden, eine Anfrage senden, deren Pfad in der erfassten Gruppe landet und mit Zeichen aufgefüllt ist, die unter Query-String-Escaping expandieren. Das Snippet unten ist nur illustrativ und absichtlich nicht waffenfähig — es zeigt die Form, die Verteidiger erkennen sollten, keinen funktionierenden Exploit.

# Schritt 1: NGINX und eine potenziell betroffene Version fingerprinten.
# (Server-Header oft vorhanden; Abwesenheit bedeutet nicht "sicher".)
curl -sI https://target.example.com/ | grep -i '^server:'
# Server: nginx/1.28.0   <-- im verwundbaren Bereich 0.6.27 - 1.30.0

# Schritt 2: Eine Route finden, die ein 'rewrite' mit einer
# unbenannten Capture trifft. Pfadsegment-Rewrites, die das Ende
# bewahren, sind die typischen Kandidaten (Legacy-Migration,
# API-Pfad-Stripping usw.).

# Schritt 3: EINE praeparierte Anfrage senden. Die erfasste Gruppe
# wird mit Zeichen (+ % &) aufgefuellt, die beim Query-String-
# Re-Escape 1 -> 3 Bytes expandieren, sodass der Schreibvorgang
# den fuer die *nicht-escapete* Laenge dimensionierten Puffer
# ueberlaeuft.
#
# *** NUR ILLUSTRATIV - KEIN FUNKTIONIERENDER EXPLOIT ***
PAD=$(python3 -c 'print("%2B" "+++%%%&&&" * 512)')
curl -sk "https://target.example.com/api/${PAD}"
# Praktisches Ergebnis fuer fast jede verwundbare Konfiguration:
#   -> Heap-Overflow im NGINX-Worker -> Absturz -> Neustart (DoS)
# Wo ASLR auf dem Host deaktiviert ist:
#   -> vom Angreifer geformte Heap-Korruption -> moegliche RCE

Eine vereinfachte Sicht auf den Größen-Mismatch:

                 ngx_http_rewrite_module
                 ------------------------

  LAENGEN-DURCHLAUF (frische Sub-Engine, is_args = 0)
     Capture "$1" ROH/nicht-escapet gemessen  ->  len = N
     malloc(N)  ............................  Puffer zu klein
                                                     |
                                                     v
  KOPIER-DURCHLAUF (Haupt-Engine, is_args = 1)
     '?' in der Ersetzung machte is_args klebrig
     ngx_escape_uri(..., NGX_ESCAPE_ARGS)
        '+'  -> "%2B"   (1 Byte  -> 3 Bytes)
        '%'  -> "%25"   (1 Byte  -> 3 Bytes)
        '&'  -> "%26"   (1 Byte  -> 3 Bytes)
     schreibt M Bytes, wobei M  >>  N
                                                     |
                                                     v
   +------------------ Heap-Chunk (N) ------------+##########
   |  geschriebene URI ...........................|  OVERFLOW
   +----------------------------------------------+##########
                                                  ^
                       angreifer-kontrollierte Bytes aus der URI

Ausnutzung in freier Wildbahn

2026-05-13 — depthfirst legt den Fehler öffentlich offen und veröffentlicht einen funktionierenden PoC auf GitHub. NVD-Eintrag geht live; AlmaLinux/Debian/Ubuntu beginnen, gepatchte Pakete auszuliefern.
2026-05-14 — F5 veröffentlicht Advisory K000161019 sowie gepatchte NGINX-Open-Source-/Plus-Builds.
2026-05-16 — Die Canary-/Honeypot-Systeme von VulnCheck melden Ausnutzungsversuche — nur drei Tage nach dem PoC.
2026-05-18 — Patrick Garrity von VulnCheck bestätigt öffentlich die aktive Ausnutzung; Berichte schätzen ~5,7 Millionen aus dem Internet erreichbare NGINX-Server auf potenziell verwundbaren Versionen.

Die realistische Bedrohung heute ist massenhafter, opportunistischer DoS: Das Absturz-Primitiv ist zuverlässig und der PoC ist öffentlich, sodass das Sprühen präparierter Anfragen gegen NGINX-Flotten, um Worker umzuwerfen, billig und reproduzierbar ist. Der RCE-Pfad ist real, aber bedingt — der öffentliche PoC erzielte Code-Ausführung gegen ein bewusst verwundbares, ASLR-deaktiviertes Ziel und demonstriert keine zuverlässige Ausführung gegen gehärtete, ASLR-aktivierte Produktions-Hosts. Behandeln Sie „DoS jetzt, RCE dort, wo bei der Härtung geschludert wurde” als Arbeitsmodell.

Auswirkungen nach erfolgreicher Ausnutzung

Service-Ausfall am Edge. NGINX ist normalerweise die Eingangstür — abstürzende Worker bedeuten verlorenes TLS, verlorene APIs und verlorenes Ingress für alles dahinter.
Reproduzierbarer, kostengünstiger Denial of Service. Eine Anfrage pro Absturz, keine Auth, keine Session — trivial gegen viele Vhosts gleichzeitig skriptbar.
Ingress-weiter Blast-Radius in Kubernetes. Das Lahmlegen von NGINX-Ingress-Controller-Pods kann den Zugriff auf jeden darüber geroutete Dienst kappen.
Code-Ausführung wo ASLR aus ist. Embedded-Appliances, minimale Container und fehlkonfigurierte Hosts mit deaktiviertem ASLR sind die realistische RCE-Population — und dort läuft der Worker oft mit genug Rechten, um zu pivotieren.
Heap-Grooming-Forschung wird besser werden. Ein 18 Jahre alter, vom Angreifer geformter Overflow mit öffentlichem PoC zieht erfahrungsgemäß Folge-Exploitation-Engineering an; die Zuverlässigkeitshürde für RCE könnte mit der Zeit sinken.

💥 Auswirkungsbewertung

Unmittelbare Auswirkung

Internet-weite Exposition: ~5,7 Mio. aus dem Internet erreichbare NGINX-Server auf einem potenziell verwundbaren Build definieren die Obergrenze der Population.
Pre-auth, eine einzige Anfrage, keine Benutzerinteraktion: die günstigsten denkbaren Trigger-Bedingungen.
Öffentlicher PoC + bestätigte Aktivität in freier Wildbahn binnen 3 Tagen: Das Fenster für „patchen, bevor es ausgenutzt wird” ist bereits geschlossen — gehen Sie davon aus, dass gesprüht wird.
Zuverlässiger DoS für nahezu alle verwundbaren Konfigurationen: kein theoretischer Randfall; der Absturz ist der Normalfall.
Bedingte RCE: ASLR-deaktivierte Hosts (Appliances, abgespeckte Container) sind das relevante Code-Ausführungs-Risiko.

Betroffene Versionen

Komponente	Verwundbarer Bereich	Behoben in
NGINX Open Source	0.6.27 bis 1.30.0	1.30.1, 1.31.0
NGINX Plus	R32 bis R36	R32 P6, R36 P4, 37.0.0
NGINX Open Source 0.6.27–0.9.7	Verwundbar	Kein Fix geplant (EOL)
NGINX Ingress Controller / F5 WAF for NGINX / Instance Manager / Gateway Fabric / App Protect DoS	Builds mit verwundbarer Engine	Vom Hersteller aktualisierte Builds — siehe K000161019

Prüfen Sie den tatsächlich laufenden Build, nicht den Paketnamen. Viele Distros backporten; nginx -v plus das Changelog Ihrer Distro ist die Quelle der Wahrheit. Ein „1.28.0” mit angewandtem Distro-Patch ist in Ordnung; ein ungepatchtes 1.30.0 nicht.

Betroffene Umgebungen

Aus dem Internet erreichbare Reverse Proxies und API-Gateways mit Pfad-Rewrite-Regeln.
Kubernetes-Cluster, die den NGINX Ingress Controller mit rewrite-target-Annotationen betreiben.
Multi-Tenant-/Template-Hosting, bei dem ein riskantes Rewrite-Snippet über viele Vhosts gerendert wird.
CDN-/WAF-Edge-Tiers auf NGINX-Basis.
Appliances und Embedded-Geräte, die NGINX bündeln — überproportional wahrscheinlich mit deaktiviertem ASLR ausgeliefert, also die RCE-relevante Population.

Angreiferprofile

Opportunistische Störer / Botnets: ein zuverlässiger, skriptbarer, unauthentifizierter Absturz gegen den häufigsten Webserver ist ideales Massen-DoS-Material.
Hacktivisten: hochsichtbare Ausfälle gegen erkennbare Ziele mit einem Einzeiler-Trigger.
Initial-Access-Akteure (selektiv): gezielte RCE-Versuche gegen ASLR-deaktivierte Appliance-Flotten.
Erpressungs-/„Booter”-Dienste: Monetarisierung eines Auth-freien Absturz-Primitivs im großen Maßstab.
Red Teams / autorisierte Tester: ein sauberer Verfügbarkeits-Testfall für jeden NGINX-vorgelagerten Scope in diesem Monat.

🛡️ Mitigationsstrategien

Sofortmaßnahmen (Priorität 1)

Jede NGINX-Instanz inventarisieren und versionsprüfen, einschließlich der in Appliances, Containern und Ingress-Controllern gebündelten.

# Direkte Hosts
nginx -v 2>&1                       # z. B. nginx version: nginx/1.30.0

# Container / Kubernetes Ingress
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | grep -i nginx | sort -u

# Flotten-Sweep ueber den Server-Header (indikativ, nicht autoritativ)
for h in $(cat hosts.txt); do
  printf '%s ' "$h"; curl -sI "https://$h/" | awk -F': ' 'tolower($1)=="server"{print $2}'
done

Auf einen behobenen Build patchen. NGINX Open Source 1.30.1 / 1.31.0; NGINX Plus R32 P6 / R36 P4 / 37.0.0; oder das gepatchte Paket Ihrer Distro (AlmaLinux/Debian/Ubuntu haben sie ausgeliefert).

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
# RHEL/AlmaLinux
sudo dnf upgrade nginx
# Nach dem Upgrade neu laden (graceful, haelt Verbindungen)
sudo nginx -t && sudo systemctl reload nginx

Den offiziellen Workaround anwenden, bis Sie patchen können: unbenannte Captures in benannte Captures umwandeln in jeder rewrite-Direktive, deren Ersetzung ein ? enthält und der ein rewrite/if/set folgt.

# Vorher (verwundbar)
rewrite ^/api/(.*)$ /internal?migrated=true;
set $original_endpoint $1;

# Nachher (sicher) -- benannte Capture vermeidet den
# fehlerhaften Codepfad
rewrite ^/api/(?<rest>.*)$ /internal?migrated=true;
set $original_endpoint $rest;

Konfigurationen auf das Trigger-Muster auditieren, damit Sie Ihre echte Exposition kennen, statt zu raten.

# rewrite-Direktiven markieren, die eine unbenannte Capture UND ein '?' nutzen
grep -RInE 'rewrite\s+\S+\s+\S*\?\S*' /etc/nginx/ | grep -E '\$[0-9]'
# Dann manuell ein folgendes rewrite/if/set im selben Block bestaetigen.

Bestätigen, dass ASLR überall aktiviert ist, wo NGINX läuft — dies ist die eine Maßnahme, die den Fehler bei „DoS” statt „RCE” hält.

cat /proc/sys/kernel/randomize_va_space   # muss 2 sein (volles ASLR)
# Falls 0/1: kernel.randomize_va_space=2 in /etc/sysctl.d setzen und anwenden.

Erkennungsmaßnahmen

# (a) Worker-Absturz/-Neustart-Signal -- der zuverlaessige DoS-Fingerprint.
journalctl -u nginx --since "2026-05-13" | \
  grep -Ei 'worker process .* exited on signal|SIGSEGV|signal 11|.*core dumped'
grep -Ei 'worker process [0-9]+ exited on signal (6|11)' /var/log/nginx/error.log

# (b) Eingehende Trigger-Form -- stark query-escapebares Padding im
#     erfassten Pfadsegment (viele +, %, & oder %2B/%25/%26-Folgen).
grep -E '"[A-Z]+ /[^ ]*(%2[B5]|%26|[+%&]){20,}' /var/log/nginx/access.log

# (c) Absturz-Stuerme -- viele Worker-Neustarts in kurzer Zeit von
#     derselben Quelle sind ein Exploitation-/DoS-Indikator, kein Rauschen.
grep -c 'exited on signal' /var/log/nginx/error.log

title: NGINX Rift (CVE-2026-42945) Trigger-Muster / Worker-Absturz
status: experimental
logsource:
  product: nginx
detection:
  uri_pattern:
    cs-uri-stem|re: '(%2[Bb5]|%26|[+%&]){20,}'
  worker_crash|re: 'worker process [0-9]+ exited on signal (6|11)'
  condition: uri_pattern or worker_crash
level: high
tags:
  - cve.2026.42945
  - attack.impact
  - attack.t1499        # Endpoint Denial of Service
  - attack.t1190        # Exploit Public-Facing Application

Langfristige Sicherheitsverbesserungen

Den Reverse Proxy als Tier-0 behandeln. Das System, das Ihr gesamtes TLS terminiert und alle Ihre Apps fronted, verdient dieselbe Patch-SLA und Monitoring-Disziplin wie ein Domain Controller.
Den laufenden NGINX-Build pinnen und tracken, nicht nur den Paketnamen — Backports lassen Server:-Header und Versionsstrings lügen. Pflegen Sie eine SBOM, die gebündelte Engines in Appliances und Ingress-Controllern einschließt.
Benannte Captures per Richtlinie bevorzugen. Linten Sie Ihre NGINX-Konfigurationen in der CI: unbenannte-Capture-Rewrites, die auch ein ? enthalten, verbieten. Dieser Fehler ist behoben, aber das Lesbarkeits-/Sicherheitsargument für benannte Captures bleibt dauerhaft.
ASLR verpflichtend halten. Erstaunlich viele Appliances und minimale Container werden mit geschwächtem ASLR ausgeliefert. ASLR ist der Unterschied zwischen Verfügbarkeitsärgernis und Remote-Shell bei dieser CVE.
Am Edge raten-limitieren und Request-Größe begrenzen. limit_req, large_client_header_buffers und vorgelagerte WAF-Regeln erhöhen die Kosten des Absturz-Sprühens schon bevor ein Patch landet.
Aggressive Advisory-SLAs für Edge-Software. Öffentlicher PoC plus bestätigte Aktivität in freier Wildbahn binnen 72 Stunden (wie hier) bedeutet, dass ein 7-Tage-Patch-Fenster für aus dem Internet erreichbares NGINX zu langsam ist — 24-72 h anstreben.

⚠️ Warum ist das kritisch?

Der meistverbreitete Webserver der Welt — ein Drittel des Webs steht hinter NGINX, und der Fehler steckt in einem seiner meistgenutzten Module.
Pre-auth, eine einzige präparierte Anfrage, keine Benutzerinteraktion — minimale Angreifervoraussetzungen.
Öffentlicher PoC am Tag der Offenlegung, Aktivität in freier Wildbahn binnen drei Tagen — das Fenster „patchen vor Ausnutzung” ist bereits weg.
Zuverlässiger DoS ist der Normalfall, nicht der Randfall — nahezu jede verwundbare Konfiguration lässt sich auf Abruf abstürzen.
Bedingte RCE auf ASLR-deaktivierten Hosts — Appliances und abgespeckte Container sind genau dort, wo ASLR am häufigsten aus ist.
18 Jahre dormant — enorme installierte Basis langlebiger, selten angefasster NGINX-Instanzen, die niemand beobachtet.
Template-Konfiguration verstärkt den Blast-Radius — ein riskantes Rewrite-Snippet, über Tausende Vhosts gerendert, ist ein Fehler, Tausende Ziele.

🗓️ Zeitleiste und Offenlegung

~2008 — Der Längen-/Kopier-Escaping-Mismatch wird im ngx_http_rewrite_module eingeführt (NGINX 0.6.27).
2026-04-21 — depthfirst meldet die Schwachstelle unter koordinierter Offenlegung an F5.
2026-05-13 — Öffentliche Offenlegung; depthfirst veröffentlicht einen funktionierenden PoC auf GitHub; NVD-Eintrag live; AlmaLinux/Debian/Ubuntu liefern gepatchte Pakete aus.
2026-05-14 — F5 veröffentlicht Advisory K000161019 und gepatchte NGINX-Open-Source-/Plus-Builds.
2026-05-16 — VulnCheck-Canary-Systeme melden die ersten Ausnutzungsversuche in freier Wildbahn.
2026-05-18 — VulnCheck bestätigt öffentlich die aktive Ausnutzung; ~5,7 Mio. exponierte Server berichtet.

🔗 Ressourcen und Referenzen

CVE: CVE-2026-42945 — MITRE
NVD: CVE-2026-42945 — NVD Detail
Hersteller-Advisory: K000161019 — NGINX ngx_http_rewrite_module vulnerability (F5)
CWE: CWE-122: Heap-based Buffer Overflow — MITRE
CISA KEV: Known Exploited Vulnerabilities Catalog (zum Zeitpunkt der Erstellung nicht gelistet)

🤝 SEKurity Unterstützt Sie

Ein Buffer Overflow, der sich achtzehn Jahre lang im populärsten Webserver der Welt versteckte — und in drei Tagen von „PoC veröffentlicht” zu „in freier Wildbahn ausgenutzt” wurde — ist eine saubere Illustration dafür, warum Edge-Software Tier-0 ist und warum „wir betreiben ein bekanntes, ausgereiftes Projekt” keine Sicherheitsmaßnahme ist. Wir helfen Organisationen, ihre echte Exposition gegenüber dieser Fehlerklasse zu messen: jeden tatsächlich laufenden NGINX-Build aufzählen (einschließlich der still in Appliances und Ingress-Controllern gebündelten), Rewrite-Konfigurationen auf das gefährliche Muster auditieren, bestätigen, dass ASLR auf den relevanten Hosts wirklich aktiviert ist, und stress-testen, ob Ihre Detection-Inhalte ein Absturz-Sprühen oder einen gezielten RCE-Versuch tatsächlich erkennen würden, bevor Ihre Kunden den Ausfall bemerken.

Unsere Leistungen

Penetration Testing: Webanwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihres Web-Edge ist unser Antrieb.

InSEKurity of the Week (CW20/2026): NGINX Rift -- 18 Jahre alter Heap-Overflow im Rewrite-Modul, unauthentifizierter DoS & moegliche RCE (CVE-2026-42945)