nginx-rift-detect

Verhaltensbasiertes Erkennungsskript für CVE-2026-42945 (NGINX Rift) – ein Heap-Pufferüberlauf in ngx_http_rewrite_module, der seit 2008 in nginx vorhanden ist.

⚠️ Haftungsausschluss

Dieses Tool ist ausschließlich für autorisierte Sicherheitstests und Forschung gedacht. Führen Sie es nur gegen Systeme aus, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Genehmigung zum Testen haben. Unbefugte Nutzung kann gegen die Computerkriminalitätsgesetze in Ihrer Rechtsordnung verstoßen. Der Autor ist nicht verantwortlich für Missbrauch oder Schäden, die durch dieses Tool verursacht werden.

Hintergrund

CVE-2026-42945 ist ein Heap-Pufferüberlauf in der Rewrite-Skript-Engine von nginx (ngx_http_rewrite_module), der in Version 0.6.27 (2008) eingeführt wurde und seit ~18 Jahren vorhanden ist.

Der Fehler entsteht durch eine Diskrepanz zwischen zwei Durchläufen der Rewrite-Engine:

• Durchlauf 1 (Längenberechnung): erkennt is_args = 0 → reserviert einen kleinen Puffer
• Durchlauf 2 (Datenkopie): erkennt is_args = 1 → ruft ngx_escape_uri auf, das jedes escapbare Byte (wie +) auf das Dreifache seiner Größe expandiert → überläuft den Heap-Puffer

Dies ermöglicht eine nicht authentifizierte Remote-Codeausführung.

Betroffene Versionen:

Referenzen:

• Originalforschung & PoC — DepthFirstDisclosures
• F5-Sicherheitshinweis K000160932

Wie die Erkennung funktioniert

Dieses Skript versucht keine RCE. Es ahmt den Ablauf des PoC mithilfe von Raw-Sockets nach:

1. Canary — sendet 3 normale Anfragen, um zu bestätigen, dass der Server vor dem Test stabil ist
2. Heap-Spray — öffnet 20 Verbindungen, um Speicher zu binden
3. Trigger — sendet GET /api/<349×A><969×+> als partielle HTTP-Anfrage
4. Probe — wenn der Trigger-Socket unerwartet geschlossen wird (Worker abgestürzt und neu gestartet), wird das Ziel als verwundbar markiert

Die Erkennung beruht darauf, dass ein Worker-Prozess zum Absturz gebracht wird. Der nginx-Master startet ihn sofort neu, aber es wird eine kurze Unterbrechung geben. Mit Vorsicht auf Produktionssystemen verwenden.

Verwendung

# Single target (HTTP)
python3 detect-CVE-2026-42945.py --host 127.0.0.1 --port 80

# Single target (HTTPS)
python3 detect-CVE-2026-42945.py --host example.com --port 443 --tls

# List of targets
python3 detect-CVE-2026-42945.py -l targets.txt

# With threading and output file
python3 detect-CVE-2026-42945.py -l targets.txt --threads 10 -o vulnerable.txt

# More attempts for unreliable targets
python3 detect-CVE-2026-42945.py --host 10.0.0.1 --port 8080 --tries 5

targets.txt-Format — ein Ziel pro Zeile:

http://example.com
https://example.com:8443
192.168.1.1
192.168.1.1:8080

Optionen:

--host          Single target host
--port          Port (default: 80, or 443 with --tls)
--tls           Use TLS/HTTPS for single target
-l, --list      File with list of targets
--tries         Detection attempts per target (default: 3)
--threads       Concurrent threads for list scan (default: 5)
-o, --output    Save vulnerable targets to CSV file

Beispielausgabe

[*] CVE-2026-42945 NGINX Rift Detection | targets=2 threads=5 tries=3

[*] http://192.168.1.1:80   - nginx/1.28.0
[*] http://192.168.1.2:8080 - nginx/1.31.0

[!!!] VULNERABLE | http://192.168.1.1:80 | nginx/1.28.0 | worker crash (trigger connection closed — worker respawned)
[+]   http://192.168.1.2:8080 - not vulnerable (or timing miss, try --tries 5)

==================================================
[*] Scan complete. 2 targets scanned.
[!!!] 1 VULNERABLE target(s):
      http://192.168.1.1:80 (nginx/1.28.0)
==================================================

Testen gegen die Lab-Umgebung

Das ursprüngliche Repository enthält eine Docker-Lab-Umgebung:

git clone https://github.com/DepthFirstDisclosures/Nginx-Rift
cd Nginx-Rift
chmod +x setup.sh && ./setup.sh
docker compose -f env/docker-compose.yml up -d

python3 detect-CVE-2026-42945.py --host 127.0.0.1 --port 19321

Lizenz

MIT — siehe LICENSE

Original-Schwachstellenforschung und PoC: DepthFirstDisclosures