CVE-2026-42945

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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

Proof of Concept (PoC)

!!Wichtig!!

  • Nur im eigenen Labor gegen eigene Systeme ausführen
  • Niemals gegen fremde Systeme

1. Präparation der nginx.conf

Der Server muss eine verwundbare Rewrite-Logik enthalten
location ~ ^/crash/(.*)$ {
    # Das Fragezeichen triggert das e->is_args Flag
    rewrite ^/crash/(.*)$ /test?check=true;
    # Die Folgeanweisung erzwingt den fehlerhaften zweiten Pfad
    set $dummy $1;
}

2. Der Angriffs-Request

Der Capture-Group-Inhalt ($1) muss Zeichen enthalten die bei gesetztem is_args-Flag expandiert werden
  • Zeichen wie +, & oder % werden von 1 Byte auf 3 Bytes expandiert
  • Die Differenz zwischen reserviertem und tatsächlich geschriebenem Speicher provoziert den Overflow
curl "http://target-server/crash/+++++++++++++++++++++++++++++++"

3. Beobachtung

Bei Erfolg erscheint im NGINX Error-Log folgende Meldung
  • Der Worker-Prozess wurde mit einem Segmentation Fault (SIGSEGV) beendet
[alert] 1234#0: worker process 5678 exited on signal 11

RCE-Exploit

Vollständige Exploits die die Cleanup-List überschreiben nutzen
  • Eine Keep-Alive-Verbindung um den Heap stabil zu halten
  • Einen präzise kalkulierten POST-Body um das gefälschte Funktions-Objekt hinter dem Puffer zu platzieren
Offizielle Exploit-Scripts werden auf Exploit-DB und GitHub unter dem Schlagwort "NGINX Rift" erwartet

Weiterführende Links

Abgerufen von „http://www.xinux.net/index.php?title=CVE-2026-42945&oldid=70049“