CVE-2026-42945

NGINX Rift — CVE-2026-42945

Eine 18 Jahre alte Memory-Corruption-Lücke in NGINX wurde im Mai 2026 durch ein KI-gestütztes Analyse-Tool entdeckt

• NGINX läuft auf ca. einem Drittel aller Webserver weltweit
• Ein unauthentizierter Angreifer kann den Server mit einem einzigen HTTP-Request zum Absturz bringen
• Auf Systemen ohne ASLR ist Remote Code Execution möglich
• Die Lücke steckt in jedem Standard-Build seit 2008

Betroffene Komponente

Das verwundbare Modul ist ngx_http_rewrite_module

• In jeder Standard-NGINX-Installation enthalten
• Verarbeitet URL-Rewrites — leitet Traffic von einer Adresse zur anderen
• Cloudflares Edge-Infrastruktur basierte ursprünglich auf NGINX

Technische Erklärung

Das grundlegende Problem

Das Rewrite-Modul verarbeitet Anweisungen in zwei Schritten

• Schritt 1: Berechnung des benötigten Speicherplatzes
• Schritt 2: Schreiben der eigentlichen Daten in den reservierten Speicher
• Beide Schritte müssen über die Größe einig sein — sind sie es nicht, entsteht ein Heap Buffer Overflow

Der fehlerhafte Flag

Ein internes Flag namens e->is_args wird nie zurückgesetzt

• Wenn eine Rewrite-Direktive ein Fragezeichen in der Replacement-URL enthält setzt NGINX e->is_args auf 1
• Schritt 1 (Größenberechnung) läuft auf einer frischen Kopie — Flag ist 0 — misst Daten als rohe Bytes
• Schritt 2 (Schreiben) läuft auf dem Haupt-Engine — Flag ist noch 1 — expandiert +, % und & von 1 Byte auf 3 Bytes
• Der Schreibvorgang ist größer als der reservierte Speicher → Overflow

Flag e->is_args:
Schritt 1 (Berechnung):  Flag = 0  →  kleine Speicherreservierung
Schritt 2 (Schreiben):   Flag = 1  →  größere Ausgabe
                                        → Overflow!

Trigger-Konfiguration

Drei Bedingungen müssen gleichzeitig erfüllt sein

• Unnamed Capture Group ($1 oder $2) in der Rewrite-Direktive
• Fragezeichen im Replacement-String
• Eine weitere Direktive direkt danach (rewrite, set oder if)

Beispiel einer verwundbaren Konfiguration

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

Named Captures sind nicht betroffen

(?<name>...)   →  nimmt einen anderen Codepfad, nicht verwundbar

Heap Feng Shui

Der Angreifer manipuliert das Memory-Layout durch gezieltes Connection-Timing

• NGINX nutzt einen Memory Pool pro Verbindung — große Blöcke werden am Stück reserviert
• Zwei Verbindungen in bestimmter Reihenfolge geöffnet → Speicherblock landet direkt neben dem Opfer-Block
• POST-Bodies können beliebige Binärdaten inkl. Null-Bytes transportieren (anders als URIs/Header)
• Über POST-Bodies wird ein gefälschter Cleanup-List-Eintrag in den Speicher geschrieben
• Der Overflow überschreibt die Adresse der Cleanup-List → NGINX führt beim Schließen der Verbindung beliebigen Code aus

NGINX Worker-Architektur als Vorteil für den Angreifer

NGINX läuft nicht als einzelner Prozess

• Ein Hauptprozess verwaltet mehrere Worker-Prozesse
• Worker verarbeiten den eigentlichen Traffic
• Crasht ein Worker startet der Hauptprozess sofort einen neuen mit identischem Memory-Layout
• Auf Systemen ohne ASLR: exakt gleiche Speicherpositionen bei jedem Neustart
• Fehlgeschlagener Exploit-Versuch crasht den Worker → sofortiger Neustart → erneuter Versuch möglich
• Unbegrenzte Wiederholungen ohne Änderung der Angriffsfläche

Weitere CVEs aus derselben Analyse

CVE	CVSS	Betroffenes Modul	Beschreibung
CVE-2026-42945	9.2 (Critical)	ngx_http_rewrite_module	Heap Buffer Overflow — Remote Code Execution
CVE-2026-42946	8.3	SCGI / uWSGI	State Mismatch — Worker berechnet Key-Länge von ~1 Terabyte → Crash
CVE-2026-40701	6.3	SSL-Modul	Use-After-Free — TLS-Verbindung schließt vor DNS-Lookup → Pointer auf freigegebenen Speicher
CVE-2026-42934	6.3	Charset-Modul	Off-by-One Read — unvollständige UTF-8-Sequenz → Lesen vor dem Speicherblock

Betroffene Versionen

• NGINX Open Source 0.6.27 bis 1.30.0
• NGINX Plus R32 bis R36
• NGINX Instance Manager 2.16.0 bis 2.21.1
• NGINX App Protect WAF 4.9.0 bis 4.16.0 und 5.1.0 bis 5.8.0
• NGINX Gateway Fabric 1.3.0 bis 1.6.2 und 2.0.0 bis 2.5.1
• NGINX Ingress Controller 3.5.0 bis 3.7.2, 4.0.0 bis 4.0.1, 5.0.0 bis 5.4.1

!!Wichtig!!

• Versionen 0.6.27 bis 0.9.7 erhalten keinen Patch — vollständiges Upgrade auf eine neuere Version nötig

Prüfen ob die eigene Konfiguration betroffen ist

Schnellcheck — nach Rewrite-Direktiven mit Fragezeichen suchen

grep -rn 'rewrite.*[?]' /etc/nginx/

Wenn keine Treffer → nicht durch CVE-2026-42945 angreifbar

Bei Treffern prüfen ob

• $1 oder $2 im Replacement vorkommt
• Direkt danach ein set, if oder weiteres rewrite folgt

Aktuelle Version prüfen

nginx -v

Mitigation

Sofortmaßnahme ohne Upgrade

Unnamed Captures durch Named Captures ersetzen — entfernt die Angriffsfläche ohne Binär-Änderung

Verwundbar

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

Nicht verwundbar

rewrite ^/api/(?<endpoint>.*)$ /internal?migrated=true;
set $original_endpoint $endpoint;

!!Wichtig!!

• Das ist ein Workaround — kein dauerhafter Ersatz für das Update

Permanente Lösung

Upgrade auf gepatchte Version

• NGINX Mainline: 1.31.0
• NGINX Stable: 1.30.1

Nach dem Upgrade NGINX neu starten damit alle Worker auf der neuen Version laufen

systemctl restart nginx

Die gepatchten Versionen beheben zusätzlich

• CVE-2026-42926 — HTTP/2 Request Injection im Proxy-Modul
• CVE-2026-40460 — Address Spoofing in HTTP/3

Hintergrund

Entdeckt von Zhenpeng (Leo) Lin, Security Researcher bei depthfirst

• depthfirst ist eine Plattform die automatisch Code auf Sicherheitslücken scannt
• Das NGINX-Repository wurde geladen und das System lieferte nach 6 Stunden 5 Memory-Corruption-Issues
• 4 davon wurden von NGINX bestätigt
• depthfirst wurde 2024 gegründet und hat im Januar 2026 40 Millionen USD Series-A-Funding erhalten
• Die Plattform hat seitdem bereits Issues im Linux-Kernel, Chrome und Apache HTTP Server gefunden

18 Jahre unentdeckt trotz tausender Entwickler und Security-Researcher die den Code reviewt haben

Weiterführende Links

• https://hackingpassion.com/nginx-rift-cve-2026-42945/ — Vollständige technische Analyse
• https://www.exploit-db.com/google-hacking-database — Exploit-DB