
🛡️ Skript zum Testen auf NGINX CVE-2026-42945
Organisationen, die NGINX Open Source, NGINX Plus oder NGINX-basierte Ingress-Controller betreiben, sollten prüfen, ob sie von CVE-2026-42945 betroffen sind, und patchen oder neu konfigurieren, bevor Exploit-Versuche Produktionsumgebungen erreichen.
Dieses Repository stellt einen schreibgeschützten, nicht-exploitativen Scanner für autorisierte defensive Zwecke auf Systemen bereit, die Sie besitzen oder testen dürfen.
| Item | Detail |
|---|
| CVE | CVE-2026-42945 |
| Name | NGINX Rift |
| Komponente | ngx_http_rewrite_module (Heap-Pufferüberlauf) |
| Betroffene Versionen | NGINX Open Source 0.6.27 bis 1.30.0 |
| Behobene Versionen | 1.30.1, 1.31.0 (+ Hersteller-Backports) |
| CVSS | 9.2 (Kritisch) |
Die Ausnutzung erfordert eine bestimmte Rewrite-Konfiguration:
rewrite-Direktive, die in der Ersetzung einen unbenannten PCRE-Capture ($1, $2, …) verwendet?rewrite-, if- oder set-Direktive im selben server/location-Gültigkeitsbereich verwendet diesen CaptureAuswirkungen:
| Prüfung | Methode |
|---|---|
| Version | Lokal nginx -v oder passiver Server-Header |
| Konfigurations-Trigger | Heuristische Analyse von nginx -T oder einer Konfigurationsdatei |
| ASLR (Linux) | /proc/sys/kernel/randomize_va_space |
| Handlungsempfehlung | Priorisierte Behebungsschritte |
Er sendet keine präparierten Exploit-Anfragen und versucht nicht, Worker zum Absturz zu bringen.
cd nginx-cve-2026-42945
chmod +x scan_nginx_rift.py
# Best: run on each NGINX host with sudo
sudo python3 scan_nginx_rift.py --local
# Or scan a full config dump
sudo nginx -T 2>&1 | tee /tmp/nginx-full.txt
python3 scan_nginx_rift.py --local --config /tmp/nginx-full.txt
# Passive remote banner check (version only)
python3 scan_nginx_rift.py --url https://your-site.example/
# JSON for automation
python3 scan_nginx_rift.py --local --json --fail-on high
Exit-Code 1, wenn das Risiko HIGH oder CRITICAL ist (verwenden Sie --fail-on, um CI-Gates anzupassen).
| Risiko | Bedeutung |
|---|---|
| CRITICAL | Verwundbare Version + Rewrite-Muster, das bekanntem Trigger entspricht |
| HIGH | Verwundbare Version und verdächtige Rewrites, oder unbekannte Version mit wahrscheinlichem Trigger |
| MEDIUM | Verwundbare Version, kein Trigger in der gescannten Konfiguration gefunden (trotzdem patchen) |
| LOW | Gepatchte Version, aber riskante Rewrite-Muster bleiben bestehen |
| INFO | Gepatcht und keine Trigger-Muster in der gescannten Konfiguration |
Führen Sie ein Upgrade auf NGINX 1.30.1 / 1.31.0+ oder das Sicherheitspaket Ihres Betriebssystems/Herstellers durch.
Starten Sie die Worker nach dem Upgrade neu (systemctl restart nginx), nicht nur per reload.
Prüfen Sie die vollständige Konfiguration: sudo nginx -T und suchen Sie nach Rewrite-Regeln mit $1/$2 und ?.
Vorübergehende Gegenmaßnahme: Verwenden Sie benannte Captures anstelle von $1, $2:
# Vulnerable pattern (simplified)
rewrite ^/api/(.*)$ /internal?migrated=true;
set $original_path $1;
# Safer pattern
rewrite ^/api/(?<path>.*)$ /internal?migrated=true;
set $original_path $path;
Bestätigen Sie, dass ASLR unter Linux aktiviert bleibt (randomize_va_space=2).
Überprüfen Sie Kubernetes-Ingress, Helm-Charts und generierte Konfigurationen — nicht nur /etc/nginx/nginx.conf.
Verwenden Sie den Scanner nur auf Infrastruktur, die Sie bewerten dürfen. Unautorisiertes Scannen kann Richtlinien oder Gesetze verletzen.