In NGINX Plus und NGINX Open Source wurde die kritische Schwachstelle CVE-2026-42945 (NGINX Rift, CVSS v4 9.2) im Modul ngx_http_rewrite_module entdeckt, die 18 Jahre lang unbemerkt blieb und Remote Code Execution oder Denial of Service über einen nicht authentifizierten HTTP‑Request ermöglicht; betroffen sind Webserver, Reverse‑Proxys, Ingress‑Controller und WAFs auf Basis von NGINX, und Administratoren müssen umgehend Versionen aktualisieren oder die Konfiguration der Rewrite‑Regeln anpassen, indem sie unsichere reguläre Ausdrücke entfernen.

Technische Details der Schwachstellen

Die ursprüngliche Schwachstelle NGINX Rift / CVE-2026-42945 wurde von Forschern des Projekts depthfirst entdeckt und in ihrer Analyse NGINX Rift ausführlich beschrieben. Laut F5‑Hinweis für NGINX‑Kunden (offizielles F5-Advisory) handelt es sich um einen buffer overflow im Heap im Modul ngx_http_rewrite_module, der bei einer spezifischen Kombination aus Direktiven und regulären Ausdrücken auftritt.

Die Bedingung für die Ausnutzung von CVE-2026-42945 sieht wie folgt aus:

• es wird das Modul ngx_http_rewrite_module mit der Direktive rewrite verwendet,
• darauf folgt eine Direktive rewrite, if oder set,
• in den Regeln werden unbenannte PCRE-Captures ($1, $2 usw.) eingesetzt,
• in der Ersetzungszeichenfolge ist das Zeichen ? vorhanden.

Ein entfernter, nicht authentifizierter Angreifer, der HTTP‑Anfragen an den verwundbaren Server senden kann, konstruiert einen speziell präparierten URI, der im NGINX‑Worker‑Prozess zu einem Heap‑Overflow führt. Bei aktiviertem ASLR ist dies mindestens ein zuverlässiger Weg, um einen Crash und Neustart des Workers (Denial of Service) auszulösen. Bei deaktiviertem ASLR wird nach Einschätzung von depthfirst und F5 Remote Code Execution im Kontext des NGINX‑Prozesses möglich. Siehe auch den Eintrag in der NVD: CVE-2026-42945.

Die Besonderheit der Schwachstelle besteht darin, dass:

• für die Ausnutzung keine Authentifizierung oder vorgelagerter Zugriff erforderlich ist;
• eine einzelne Anfrage ausreicht, um einen Heap‑Overflow auszulösen;
• die Bytes, die außerhalb des zugewiesenen Blocks geschrieben werden, durch den Angreifer über den URI vollständig kontrolliert werden, was die Speicherkorruption zielgerichtet statt zufällig macht;
• wiederholte Anfragen die Worker‑Prozesse in eine Absturzschleife bringen können, was die Verfügbarkeit aller auf der Instanz gehosteten Sites reduziert.

Nach Angaben von F5 betrifft die Schwachstelle:

• NGINX Plus R32–R36 (behoben in R32 P6 und R36 P4);
• NGINX Open Source 1.0.0–1.30.0 (behoben in 1.30.1 und 1.31.0);
• NGINX Open Source 0.6.27–0.9.7 (keine Fixes geplant);
• eine Reihe von NGINX-basierten Produkten: NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS, NGINX Gateway Fabric, NGINX Ingress Controller — in den im F5-Advisory aufgeführten spezifischen Versionsbereichen.

Zusätzliche Schwachstellen in NGINX

Gleichzeitig wurden drei weitere Schwachstellen mittlerer bis hoher Schwere behoben:

• CVE-2026-42946 (CVSS v4 8.3) — übermäßige Speicherallokation in den Modulen ngx_http_scgi_module und ngx_http_uwsgi_module. Ein nicht authentifizierter Angreifer mit der Möglichkeit, Antworten des Upstream‑Servers abzufangen und zu verändern (adversary-in-the-middle), kann Antworten so gestalten, dass NGINX den Speicher des Worker‑Prozesses fehlerhaft verwaltet, was zu einem Auslesen von Daten aus dessen Speicher oder zum Neustart des Prozesses beim Einsatz der Direktiven scgi_pass oder uwsgi_pass führt. Siehe das Advisory zu CVE-2026-42946 und den Eintrag CVE-2026-42946.
• CVE-2026-40701 (CVSS v4 6.3) — use-after-free in ngx_http_ssl_module. Bedingung: ssl_verify_client ist auf on oder optional gesetzt und ssl_ocsp auf on. Dies ermöglicht es einem entfernten, nicht authentifizierten Angreifer in begrenztem Umfang, Daten zu verändern oder einen Neustart des Worker‑Prozesses auszulösen. Siehe das Advisory zu CVE-2026-40701 und CVE-2026-40701.
• CVE-2026-42934 (CVSS v4 6.3) — Lesen außerhalb des Puffers in ngx_http_charset_module. Es besteht das Risiko der Offenlegung von Speicherinhalten oder eines Worker‑Neustarts bei gleichzeitiger Konfiguration der Direktiven charset, source_charset, charset_map und proxy_pass mit deaktiviertem Buffering (off). Siehe das Advisory zu CVE-2026-42934 und CVE-2026-42934.

In den ursprünglichen Hinweisen ist nicht von bestätigter Ausnutzung dieser Schwachstellen in realen Angriffen die Rede, aber das technische Profil von CVE-2026-42945 macht sie zu einem attraktiven Ziel für Automatisierung und massenhaftes Scanning.

Kontext und Besonderheiten der Bedrohung

NGINX wird traditionell als hochskalierbarer Webserver und Reverse‑Proxy sowie als Basis für Ingress‑Controller in Kubernetes und kommerzielle F5‑Lösungen eingesetzt. Der Fehler im Rewrite‑Mechanismus, der seit frühen Versionen (0.6.x) existiert, zeigt exemplarisch die Risiken von „Grenzlogik“: ungewöhnliche Kombinationen von Direktiven, Integration mit PCRE und komplexe URI‑Templates werden historisch schlechter getestet, finden aber in realen Konfigurationen breite Anwendung.

Von kritischer Bedeutung ist, dass der verwundbare Codepfad erreicht wird, bevor irgendeine Applikationsauthentifizierung oder Business‑Logik greift. De facto tritt NGINX hier selbst als Angriffsoberfläche auf. Das erhöht den Wert der Schwachstelle für Angreifer: Es genügt die reine Netz‑Erreichbarkeit des HTTP‑Ports, selbst wenn hinter NGINX ein gut abgesicherter Backend‑Dienst verborgen ist.

Die zusätzlichen Schwachstellen (SCGI/UWSGI, SSL, Charset) illustrieren eine andere Klasse von Problemen: Wenn NGINX den Inhalten des Upstream‑Servers oder der Zertifikatsprüfinfrastruktur (OCSP) vertraut, können Fehler bei der Verarbeitung dieser Daten dazu führen, dass die erwarteten Speichergrenzen überschritten werden. In Szenarien, in denen der Angreifer Upstream‑Antworten kontrolliert oder manipulieren kann, werden solche Defekte zu einem mächtigen Instrument, um Speicherfragmente auszulesen oder Dienste außer Betrieb zu setzen.

Auswirkungsbewertung

Am stärksten gefährdet sind:

• Organisationen, die NGINX als öffentlichen Webserver oder Reverse‑Proxy mit aktiviertem ngx_http_rewrite_module nutzen, insbesondere mit einer großen Zahl komplexer Regeln;
• Cloud‑ und Hosting‑Provider, bei denen eine NGINX‑Instanz viele Mandanten bedient: Eine erfolgreiche Ausnutzung von CVE-2026-42945 kann alle Kunden auf diesem Knoten beeinträchtigen;
• Kubernetes‑Cluster mit NGINX Ingress Controller sowie Installationen von NGINX App Protect WAF/DoS und NGINX Gateway Fabric in verwundbaren Versionen;
• Systeme, in denen ASLR deaktiviert oder abgeschwächt ist (z. B. spezialisierte Appliances oder stark auf Performance optimierte Umgebungen).

Ohne Gegenmaßnahmen sind folgende Folgen möglich:

• vollständige Kompromittierung des Hosts durch RCE im NGINX‑Prozess (CVE-2026-42945) mit anschließendem lateralen Bewegungsspielraum im Netz;
• Kompromittierung vertraulicher Daten durch Auslesen von Speicherfragmenten des Worker‑Prozesses (CVE-2026-42946, CVE-2026-42934), in denen sich Tokens, Cookies sowie Teile von Requests und Responses befinden können;
• großflächiger Denial of Service — zyklische Abstürze der Worker‑Prozesse, Nichtverfügbarkeit von Websites und APIs, erhöhte Latenzen und 502/504‑Fehler;
• indirekte Schäden: Reputationsverluste, SLA‑Verletzungen, mögliche Bußgelder aufgrund von Lecks personenbezogener Daten.

Praktische Empfehlungen

1. Priorisierung und Zeitrahmen

• Betrachten Sie CVE-2026-42945 als kritisch: Update oder Workaround haben die Priorität „sofort/innerhalb der nächsten Stunden“ auf öffentlich erreichbaren Systemen.
• Die übrigen Schwachstellen (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — Priorität „hoch“, Update im nächsten Wartungsfenster einplanen.

2. Update auf fehlerbereinigte Versionen

• Für NGINX Plus mindestens auf R32 P6 oder R36 P4 beziehungsweise neuere Releases mit Fixes aktualisieren (siehe F5-Advisory).
• Für NGINX Open Source — auf 1.30.1 oder 1.31.0 und höher migrieren.
• Für NGINX-basierte Produkte (Ingress Controller, App Protect WAF/DoS, Gateway Fabric, Instance Manager, F5 WAF for NGINX) — die aktuellen Versionen mit den in den jeweiligen F5‑Advisories aufgeführten Bereichen abgleichen und auf die empfohlenen Releases aktualisieren.
• Für sehr alte Zweige 0.6.27–0.9.7, für die keine Fixes geplant sind, bleibt nur die Migration auf unterstützte Versionen.

3. Workaround für CVE-2026-42945

Wenn ein sofortiges Update nicht möglich ist, sollte die Konfiguration der Rewrite‑Regeln wie von F5 und depthfirst beschrieben geändert werden:

• Alle rewrite-Direktiven finden, auf die rewrite, if oder set folgt und bei denen:
  • unbenannte Captures vom Typ $1, $2 usw. verwendet werden;
  • in der Ersetzungszeichenfolge das Zeichen ? vorkommt.
• Die regulären Ausdrücke auf benannte Captures von PCRE umstellen, beispielsweise:
  • vorher: rewrite ^/user/(\d+)\?(.*)$ /profile.php?id=$1?$2;
  • nachher: rewrite ^/user/(?<uid>\d+)\?(?<rest>.*)$ /profile.php?id=$uid?$rest;
• Nach den Änderungen prüfen, dass die Funktionalität der Weiterleitungen erhalten bleibt, und NGINX neu starten.

Der Kern des Workarounds: Die Umstellung von unbenannten auf benannte Captures ändert den Datenverarbeitungspfad im NGINX‑Code und schließt das verwundbare Szenario aus.

4. Risikoreduzierung bei den zusätzlichen Schwachstellen

Bis zum Update kann die Angriffsfläche vorübergehend reduziert werden:

• Für CVE-2026-42946: wenn möglich scgi_pass und uwsgi_pass an äußeren Grenzen einschränken oder vorübergehend deaktivieren, insbesondere dort, wo der Upstream unter Kontrolle Dritter stehen kann.
• Für CVE-2026-40701: bei geringer Kritikalität von Client‑Zertifikatsprüfung und OCSP die vorübergehende Deaktivierung von ssl_ocsp on oder die Abschwächung von ssl_verify_client erwägen, dabei jedoch die Auswirkungen auf die Anforderungen an die Client‑Authentifizierung bewerten.
• Für CVE-2026-42934: den Einsatz von charset_map in Kombination mit proxy_pass und deaktiviertem Buffering minimieren, sofern dies ohne geschäftliche Einbußen möglich ist.

5. Prüfung auf Betroffenheit und Monitoring

• Die NGINX‑Version mit dem Befehl nginx -v prüfen und mit den Bereichen der verwundbaren Versionen abgleichen.
• Die Konfiguration analysieren:
  • Suche in nginx.conf und eingebundenen Dateien nach den Stichwörtern rewrite, $1, $2, ?;
  • Regeln herausfiltern, die dem oben beschriebenen Muster entsprechen.
• Fehlerlogging von NGINX und Systemlogging aktivieren oder verschärfen:
  • auf wiederkehrende Abstürze von Worker‑Prozessen, segmentation fault-Signale und zyklische Neustarts achten;
  • diese Ereignisse mit verdächtigen HTTP‑Requests mit ungewöhnlichen URIs, ? und komplexen Mustern korrelieren.
• Sicherstellen, dass auf den Servern ASLR auf Betriebssystemebene aktiviert ist, als zusätzliche Schutzschicht gegen RCE — auch nach Installation der Patches.

Die zentrale Maßnahme für Betreiber von NGINX‑basierter Infrastruktur besteht darin, NGINX Plus, NGINX Open Source und zugehörige Produkte so schnell wie möglich auf Versionen mit Fixes für CVE-2026-42945 und die begleitenden Schwachstellen zu aktualisieren und bei Verzögerungen des Updates unverzüglich eine Überprüfung der Rewrite‑Regeln durchzuführen, bei der in allen aus dem Internet erreichbaren Konfigurationen unbenannte durch benannte Captures ersetzt werden.