NGINX Rift: 18 Jahre alter Fehler wird aktiv ausgenutzt
In NGINX steckt eine kritische Sicherheitslücke, die seit 2008 unentdeckt im Code schlummerte. Angreifer nutzen sie bereits aus, um Webserver lahmzulegen und in seltenen Fällen Schadcode einzuschleusen. Betroffen sind Millionen von Servern weltweit.
Was ist passiert?
Sicherheitsforscher des Unternehmens depthfirst haben am 18. April 2026 mittels automatisierter Analyse vier Speicherkorruptionsfehler im NGINX-Quellcode entdeckt. Der gravierendste davon, CVE-2026-42945, steckt im ngx_http_rewrite_module und wurde am 13. Mai 2026 zusammen mit einem Patch von F5 veröffentlicht. Weniger als 72 Stunden nach der Veröffentlichung registrierten VulnChecks Honeypot-Systeme bereits erste aktive Angriffsversuche.
Die Schwachstelle trägt den Namen „NGINX Rift“ und erhält einen CVSS4-Score von 9.2 (kritisch). Der zugrundeliegende Fehler wurde 2008 in den Code eingebracht und blieb seitdem unbemerkt.
Wie funktioniert der Angriff?
Das Rewrite-Modul von NGINX berechnet zunächst die benötigte Puffergröße für eine umgeschriebene URL und kopiert dann die Daten in diesen Puffer. Genau hier liegt das Problem: Wenn eine rewrite-Direktive unbenannte PCRE-Captures (also $1, $2 etc.) verwendet und die Ersetzungszeichenkette ein Fragezeichen enthält, gefolgt von einer weiteren rewrite-, if- oder set-Direktive, geraten die internen Zustandsvariablen des Moduls aus dem Takt.
Die Längenberechnung geht von unkodiertem Text aus, der eigentliche Kopiervorgang escaped die Zeichen jedoch zusätzlich. Sonderzeichen wie +, % oder & belegen nach dem Escaping drei statt einem Byte. Das Ergebnis: Der Schreibvorgang läuft über den reservierten Speicherbereich hinaus, ein klassischer Heap-Buffer-Overflow.
Ein nicht authentifizierter Angreifer aus dem Internet kann durch einen einzigen präparierten HTTP-Request den NGINX-Worker-Prozess zum Absturz bringen (Denial of Service). Ist auf dem betroffenen System die Address Space Layout Randomization (ASLR) deaktiviert, was in der Praxis selten vorkommt, ist sogar Remote Code Execution möglich.
Wer ist betroffen?
Die Lücke steckt in jeder Standardinstallation von NGINX, sofern die anfällige Konfigurationskombination verwendet wird. Konkret betroffen sind:
- NGINX Open Source, Versionen 0.6.27 bis 1.30.0
- NGINX Plus R32 bis R36
- NGINX Ingress Controller 3.5.0 bis 3.7.2, 4.0.0 bis 4.0.1, 5.0.0 bis 5.4.1
- NGINX Gateway Fabric 1.3.0 bis 1.6.2 und 2.0.0 bis 2.5.1
- NGINX App Protect WAF und DoS sowie F5 WAF für NGINX in mehreren Versionen
- NGINX Instance Manager 2.16.0 bis 2.21.1
Laut VulnCheck sind derzeit rund 5,7 Millionen NGINX-Instanzen über das Internet erreichbar. Nicht betroffen sind F5 Distributed Cloud, BIG-IP, F5OS und NGINX One Console.
- NGINX auf eine der gepatchten Versionen aktualisieren.
- NGINX Open Source: Update auf 1.31.0 oder 1.30.1 NGINX Plus R36: Update auf R36 P4 NGINX Plus R32: Update auf R32 P6
- Nach dem Update NGINX neu starten, damit die Worker-Prozesse das gepatche Binary laden.
