srkyn/nginx-map-risk-auditDefensives NGINX-CVE-2026-42533-Map-Regex-Risikoaudit mit Konfigurationsscanner, Splunk/Defender-Notizen und Labornachweisen.
Defensive Forschungsnotiz zu CVE-2026-42533, einem Heap-Pufferüberlauf in der NGINX-Anfrageverarbeitung, der mit map-Direktiven samt Regex-Captures und bestimmten Variablenauswertungsmustern zusammenhängt.
Einfach ausgedrückt: NGINX ist eine Webserver- und Reverse-Proxy-Software. Sie sitzt häufig vor Websites und APIs, nimmt Webanfragen entgegen und entscheidet, wohin sie gesendet werden. Eine map-Regel ist ein NGINX-Konfigurationsfeature, das besagt: „Wenn dieser Anfragewert wie X aussieht, setze diese Variable auf Y." Regex-Captures sind die Textteile, die aus einem Musterabgleich extrahiert werden.
Diese CVE ist relevant, weil einige ältere NGINX-Versionen eine bestimmte Art von map- und Variablenkombinationsmuster falsch verarbeiten können. Das bedeutet nicht, dass jeder NGINX-Server betroffen ist. Die Version ist entscheidend, aber auch die aktive Konfiguration spielt eine Rolle.
Dieses Projekt ist bewusst sicher: Es enthält weder Exploit-Traffic, Crash-Payloads noch Produktivsystem-Scans. Das Ziel ist zu zeigen, wie ich die Gefährdung triagieren würde, das Risiko zu erklären und Verteidigern einen wiederholbaren Validierungspfad an die Hand zu geben.
NGINX führt das Problem als wichtiges Sicherheitsadvisory: Betroffene Versionen sind 0.9.6-1.31.2, behobene Versionen sind 1.30.4+ und 1.31.3+. Das NGINX-Changelog beschreibt einen Heap-Pufferüberlauf in einem Worker-Prozess, wenn eine map-Direktive Regex-Abgleich verwendet und die Map-Variable in einem String-Ausdruck nach einem von dieser Map betroffenen Capture eingebunden wird.
Die NVD führt die F5-Beschreibung auf: Ein nicht authentifizierter Angreifer kann das Problem mit präparierten HTTP-Anfragen auslösen, jedoch nur, wenn Konfigurations- und Laufzeitbedingungen zusammenpassen. Die zu erwartende direkte Auswirkung ist ein Neustart des NGINX-Workers und Denial of Service, mit möglicher Codeausführung, wenn ASLR deaktiviert oder umgangen wird.
Verteidiger sollten vier Fragen beantworten, bevor sie eine NGINX-Bereitstellung als betroffen einstufen. Einfach gesagt: Zuerst die Version bestätigen, dann prüfen, ob das riskante Konfigurationsmuster tatsächlich vorhanden ist.
map mit Regex-Einträgen?no buffer space in script copy in den Logs sichtbar?Falls diese Begriffe neu sind: Ein Worker ist der NGINX-Prozess, der Anfragen verarbeitet. Ein Crash-Loop oder Neustartsignal bedeutet, dass der Prozess möglicherweise ausfällt und neu startet. Ein Distro-Backport bedeutet, dass Linux-Anbieter manchmal eine älter aussehende Version patchen, ohne die Versionsnummer auf die neueste Upstream-Veröffentlichung zu ändern.
flowchart LR
advisory["Read advisory and changelog"] --> version["Check NGINX version"]
version --> config["Review active config"]
config --> scanner["Run safe map-pattern scanner"]
scanner --> validate["Validate fixed build or vendor patch"]
validate --> hunt["Hunt restart and diagnostic signals"]
hunt --> remediate["Patch, reload, and document"]
scripts/audit_nginx_map_risk.py
Ein defensiver heuristischer Scanner für NGINX-Konfigurationsdateien. Er sucht nach Regex-map-Blöcken, Captures und späteren String-Ausdrücken, die Captures und Map-Ausgaben referenzieren. Er beweist nicht, dass ein Server ausnutzbar ist. Er findet Konfigurationen, die eine manuelle Prüfung wert sind.
scripts/render_demo_gif.py
Baut das kleine README-Demo-GIF aus echten Scanner-Ausgaben neu zusammen.
detections/splunk_nginx_cve_2026_42533.spl
Splunk-Suchen für Versionsinventar, Crash-/Neustartsymptome und Diagnosestrings nach dem Patch.
detections/defender_hunting_notes.kql
Microsoft-Defender-Hunting-Notizen für Linux-Hosts, auf denen NGINX-Logs und Prozessaktivität gesammelt werden.
detections/sigma_nginx_worker_restart_symptoms.yml
Sigma-Hunting-Regel für NGINX-Worker-Neustart- oder Crash-Symptome. Sie ist ein Hinweis zur Prüfung, kein Beweis für eine Ausnutzung.
samples/nginx_map_patterns.conf
Sichere, schematische Konfigurationsbeispiele zur Erläuterung des Risikomusters. Es handelt sich nicht um Exploit-Payloads.
SECURITY.md
Geltungsbereichshinweis für das Repository. Das hält das Projekt klar defensiv und sicher zu prüfen.
Die aktuelle lokale Validierung wird in evidence/ gespeichert. Der Windows-Quickstart führt den Scanner gegen die enthaltene Beispielkonfiguration aus und speichert das Transkript. Die Windows-NGINX-Validierung lädt den offiziellen behobenen NGINX-Build herunter, bestätigt die Labor-Konfiguration mit nginx -t und führt den Scanner aus. Die Kali-VM-Validierung führt denselben Scanner in einer wegwerfbaren Kali-VMware-Gastinstanz aus. Das beweist, dass das Repository unter Windows und Linux ausführbar und prüfbar ist, während das Projekt innerhalb einer defensiven Grenze bleibt.
powershell -ExecutionPolicy Bypass -File .\lab\windows-quickstart.ps1
powershell -ExecutionPolicy Bypass -File .\lab\windows-nginx-validation.ps1
python .\scripts\self_check.py
map-Blöcken durchsuchen.1.30.4+ oder 1.31.3+ patchen oder auf das relevante behobene NGINX-Plus-Release.no buffer space in script copy überwachen.lab/windows-quickstart.ps1
Windows-freundlicher Beweis-Runner, der den Scanner ausführt und die Ausgabe unter evidence/ speichert.
lab/windows-nginx-validation.ps1
Lädt den offiziellen behobenen NGINX-Build für Windows herunter, validiert eine lokale Labor-Konfiguration mit nginx -t, führt den Scanner aus und speichert die Nachweise.
lab/vmware-lab-notes.md
Optionaler, umfassenderer Laborpfad für eine wegwerfbare Linux-VM, falls später ein screenshotbasierter Durchlauf benötigt wird.