Mit CVE-2026-42945 wurde eine der schwerwiegendsten Schwachstellen der letzten Jahre im NGINX-Ökosystem veröffentlicht. Die Sicherheitslücke trägt den Namen „NGINX Rift“ und betrifft sowohl NGINX Open Source als auch NGINX Plus. Besonders brisant: Der Bug existierte offenbar seit rund 18 Jahren im Code und ermöglicht unter bestimmten Konfigurationen Remote Code Execution (RCE) – ohne Authentifizierung und allein durch manipulierte HTTP-Anfragen.

Zusammenfassung

Mit einem CVSS v4.0 Score von 9.2 (Critical) gehört die Lücke zu den gefährlichsten öffentlich bekannten Webserver-Schwachstellen der letzten Zeit.

Ein Fehler im ngx_http_rewrite_module führt zu einem Heap-based Buffer Overflow innerhalb eines NGINX-Worker-Prozesses. Ein Angreifer kann speziell präparierte URIs senden, um Speicherbereiche außerhalb des vorgesehenen Buffers zu überschreiben.

Die Schwachstelle tritt auf, wenn folgende Bedingungen erfüllt sind:

• eine rewrite-Direktive verwendet unnamed regex captures wie $1 oder $2
• der Replacement-String enthält ein Fragezeichen (?)
• danach folgt eine weitere rewrite, if oder set-Direktive im selben Scope

Unter diesen Umständen berechnet NGINX die Zielgröße des Buffers falsch und schreibt anschließend mehr Daten hinein als vorgesehen. Das Resultat ist ein deterministischer Heap Overflow, der sich für Remote Code Execution missbrauchen lässt.

Warum diese Schwachstelle so kritisch ist

NGINX steht heute vor einem erheblichen Teil des öffentlichen Internets — von kleinen Blogs bis zu globalen Cloud-Plattformen.

Das macht CVE-2026-42945 besonders gefährlich:

• keine Authentifizierung erforderlich
• direkt aus dem Internet erreichbar
• ein einzelner HTTP-Request genügt
• kontrollierbare Speicher-Korruption
• potenziell vollständige Übernahme des Worker-Prozesses

Da die überschriebenen Bytes direkt aus der manipulierten URI stammen, kann ein Angreifer die Heap-Korruption gezielt beeinflussen. Neben RCE sind auch dauerhafte Crash-Loops denkbar, wodurch Websites effektiv lahmgelegt werden können.

Wichtig:
Die Schwachstelle betrifft ausschließlich den Request-Handling-Pfad. Es gibt derzeit keine Hinweise auf eine direkte Kompromittierung der NGINX-Control-Plane.

Welche Systeme betroffen sind

Die Schwachstelle steckt im Modul ngx_http_rewrite_module, das Bestandteil praktisch jeder Standard-NGINX-Installation ist.

NGINX Open Source

• Versionen 0.6.27 bis 1.30.0

NGINX Plus

• Releases R32 bis R36

Weitere betroffene Produkte:

• NGINX Instance Manager 2.16.0 – 2.21.1
• F5 WAF for NGINX 5.9.0 – 5.12.1
• NGINX App Protect WAF 4.9.0 – 4.16.0 sowie 5.1.0 – 5.8.0
• NGINX Gateway Fabric 1.3.0 – 1.6.2 sowie 2.0.0 – 2.5.1
• NGINX Ingress Controller 3.5.0 – 5.4.1

Nicht betroffen sind laut Advisory unter anderem:

• F5 Distributed Cloud
• F5 Silverline
• BIG-IP
• BIG-IQ
• F5OS
• NGINX One Console

So funktioniert der Angriff

Die eigentliche Ursache liegt tief in src/http/ngx_http_script.c.

Vereinfacht gesagt:

1. NGINX verarbeitet einen rewrite mit ? im Zielpfad
2. intern wird is_args = 1 gesetzt
3. später wird die notwendige Buffer-Größe neu berechnet
4. dabei nutzt NGINX unterschiedliche Escaping-Regeln
5. Sonderzeichen wie +, % oder & werden plötzlich größer als erwartet
6. der Schreibvorgang läuft über das Ende des Buffers hinaus

Dadurch entsteht ein klassischer Heap Overflow.

Besonders problematisch ist dabei, dass der Angreifer die geschriebenen Daten teilweise kontrollieren kann — eine ideale Voraussetzung für Exploitation.

Verwundbare Konfiguration

Unsichere Rewrite-Regel

rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

Diese Konfiguration nutzt unnamed captures ($1, $2) und ist daher potenziell angreifbar.

Sichere Alternative

Die empfohlene Mitigation besteht darin, named captures zu verwenden.

Abgesicherte Rewrite-Regel

rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Damit wird der fehlerhafte Verarbeitungspfad umgangen.

Welche Updates verfügbar sind

Sofort patchen

Folgende Versionen beheben die Schwachstelle:

Nach dem Upgrade muss NGINX vollständig neu gestartet werden, damit alle Worker den gepatchten Binary-Code laden.

Was tun, wenn ein Upgrade aktuell nicht möglich ist?

Falls kurzfristig kein Patch eingespielt werden kann:

1. alle rewrite-Regeln prüfen
2. unnamed captures ($1, $2) identifizieren
3. auf named captures umstellen
4. besonders Regeln mit ? im Replacement-String überprüfen

Zusätzlich sinnvoll:

• WAF-Regeln aktivieren
• ungewöhnliche URI-Patterns loggen
• Worker-Crashes überwachen
• ASLR und aktuelle libc-Versionen einsetzen

Diese Maßnahmen verhindern die Schwachstelle nicht vollständig, erschweren aber eine zuverlässige Ausnutzung.

Warum „NGINX Rift“ ein Weckruf ist

Die Schwachstelle zeigt erneut, wie gefährlich jahrzehntealte Parsing- und Memory-Management-Fehler in kritischer Infrastruktur sein können.

NGINX gilt seit Jahren als extrem stabil und performant. Gerade deshalb dürften viele Organisationen überrascht sein, dass ein so alter Fehler unentdeckt blieb — und gleichzeitig so gravierende Auswirkungen haben kann.

Besonders in Kubernetes-Umgebungen mit Ingress-Controllern oder API-Gateways könnte die Angriffsfläche enorm sein.

Fazit

CVE-2026-42945 ist keine theoretische Edge-Case-Schwachstelle, sondern ein realistisch ausnutzbarer Heap Overflow in einer der wichtigsten Webserver-Komponenten des Internets.

Wer NGINX betreibt, sollte jetzt:

• betroffene Versionen identifizieren
• Rewrite-Konfigurationen auditieren
• schnellstmöglich patchen
• Logs und Worker-Prozesse überwachen

Da der Angriff ohne Authentifizierung funktioniert und lediglich eine HTTP-Anfrage benötigt, ist die Hürde für Angreifer extrem niedrig. Für viele Unternehmen dürfte das eines der wichtigsten Infrastruktur-Updates des Jahres 2026 werden.

Quellen / Writeup:
– Allgemeiner Writeup: https://depthfirst.com/nginx-rift
– Technische Details: https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability