
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$1oder$2 - Der Replacement-String enthält ein Fragezeichen (
?) - Danach folgt eine weitere
rewrite,ifoderset-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:
NGINX verarbeitet einen rewrite mit ? im Zielpfad.
Intern wird is_args = 1 gesetzt.
Später wird die notwendige Buffer-Größe neu berechnet.
Dabei nutzt NGINX unterschiedliche Escaping-Regeln.
Sonderzeichen wie +, % oder & werden plötzlich größer als erwartet.
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 und sichere Alternative
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.
Abgesicherte Rewrite-Regel mit Named Captures
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
Die empfohlene Mitigation besteht darin, named captures zu verwenden. Damit wird der fehlerhafte Verarbeitungspfad umgangen.
Welche Updates verfügbar sind
Folgende Versionen beheben die Schwachstelle:
- NGINX Open Source: gefixt in
1.30.1und1.31.0 - NGINX Plus R32: gefixt in
R32 P6 - NGINX Plus R36: gefixt in
R36 P4
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:
- Alle
rewrite-Regeln prüfen - Unnamed captures (
$1,$2) identifizieren - Auf named captures umstellen
- 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.
Mint Secure GmbH
Fazit: Was betroffene Unternehmen jetzt tun sollten
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.
Wie Mint Secure euch dabei unterstützt
Ob Identifikation betroffener Systeme, Absicherung während der Patch-Phase oder Reaktion im Ernstfall: Wir unterstützen euch in jeder Phase.
Incident Response
Aktive Vorfallsreaktion mit garantierten Reaktionszeiten, falls die Schwachstelle bereits ausgenutzt wurde.
Penetration Testing
Wir prüfen, ob eure NGINX-Konfiguration und weitere Angriffsflächen real ausnutzbar sind.
Ransomware Emulation
Simulation, wie weit ein Angriff über eine solche RCE-Lücke in eurer Umgebung käme.
Security Beratung
Unterstützung beim Patch- und Vulnerability-Management-Prozess, damit solche Lücken künftig schneller auffallen.
Unsicher, ob ihr betroffen seid? Wir prüfen eure NGINX-Konfiguration gemeinsam mit euch. Jetzt Kontakt aufnehmen.
Fazit
Ein 18 Jahre alter Fehler, ausnutzbar mit einer einzigen HTTP-Anfrage: CVE-2026-42945 gehört zu den kritischsten NGINX-Lücken der letzten Jahre.
Wer NGINX Open Source, NGINX Plus oder eines der betroffenen F5-Produkte betreibt, sollte umgehend patchen und Rewrite-Regeln auditieren.
Mint Secure unterstützt euch von der Schwachstellenanalyse bis zur Absicherung eurer Infrastruktur. Sprecht uns an.
Quellen: Allgemeiner Writeup · Technische Details

