NGINX-Lücke: Ingress und Gateway im Patch-Zwang
CVE-2026-42533 trifft NGINX samt Ingress und Gateway. Was Cluster-Teams prüfen und patchen müssen.
F5 hat CVE-2026-42533 gepatcht: eine Heap-Buffer-Overflow-Lücke in NGINX, die bis Version 0.9.6 zurückreicht. Für Cloud-Teams zählt weniger die Historie als der Blast Radius – Ingress Controller, Gateway Fabric und App Protect sitzen oft genau vor den Workloads.
Das Wichtigste in Kürze
- CVE-2026-42533. Unauthentifizierte, remote auslösbare Heap-Overflow in der NGINX-Script-Engine bei bestimmten Regex-map-Konfigurationen. F5: CVSS v4 9.2 / v3.1 8.1; Fix in Open Source 1.30.4 (stable) und 1.31.3 (mainline) sowie NGINX Plus 37.0.3.1.
- Cloud-Blast-Radius. Betroffen sind laut Advisory und Security-Research auch NGINX Ingress Controller, Gateway Fabric, App Protect WAF und Instance Manager – also genau die Schicht, die in Kubernetes-Clustern Internet-Traffic terminiert.
- Kein flächendeckender RCE-Default. DoS (Worker-Crash) ist der belastbare Effekt; Remote Code Execution knüpft F5 an deaktiviertes oder umgehbares ASLR. Trotzdem: Jetzt patchen, unabhängig vom PoC-Status.
Verwandt:Argo-CD-Lücke: Cluster-Übernahme / Ingress-NGINX ist abgekündigt
Die Lücke steckt in der Script-Engine: dem Code, der aus Direktiven zur Request-Zeit Strings zusammensetzt. Auslöser ist eine enge Konfigurationskombination – eine Regex-basierte map, deren Ausgabevariable in einem String-Ausdruck nach einer Capture-Variable aus einem früheren Regex-Match referenziert wird.
Technisch reißt der Zwei-Pass-Lauf auseinander. Der erste Pass misst die benötigte Pufferlänge, der zweite schreibt die Bytes. Beide greifen auf denselben Capture-State zu. Wertet die Engine dazwischen die Map-Regex aus, überschreibt sie diesen State. Der Mess-Pass dimensioniert den Puffer für die ursprüngliche Capture (etwa $1 aus dem Location-Match), der Schreib-Pass füllt ihn mit einer anderen, vom Request beeinflussbaren. Der Puffer ist zu klein – Länge und Inhalt des Überlaufs kommen aus dem HTTP-Request.
Was ist CVE-2026-42533? CVE-2026-42533 ist eine Heap-Buffer-Overflow-Schwachstelle (CWE-122) in NGINX Open Source und NGINX Plus. Sie entsteht, wenn die Script-Engine bei Regex-map-Direktiven Capture-Variablen falsch verarbeitet. Ein entfernter Angreifer ohne Login kann damit Worker-Prozesse zum Absturz bringen und unter engen Bedingungen potenziell Code ausführen. Betroffen sind Versionen von 0.9.6 bis 1.31.2 – der relevante Zeitraum beginnt 2011 mit der Regex-Unterstützung in map.
Warum das Cloud- und Kubernetes-Teams trifft
Nicht jeder NGINX-Server ist ausnutzbar. Die Exposition hängt von der Konfiguration ab, nicht nur von der Versionsnummer. Genau das macht die Lage unangenehm: Inventar nach „NGINX ja/nein“ reicht nicht. Teams brauchen einen Config-Scan auf die enge Map-plus-Capture-Musterfolge.
Im Cluster multipliziert sich das Risiko. NGINX sitzt als Ingress Controller, als Teil von Gateway-Stacks oder als WAF-Schicht vor Services. F5 listet neben Core und Plus ausdrücklich NGINX Ingress Controller, Gateway Fabric, App Protect WAF und Instance Manager. Security-Research (unter anderem Orca) konkretisiert betroffene Ingress-Controller-Versionsspannen und fordert Updates der jeweiligen Patched Builds. Parallel läuft im Ökosystem ohnehin die Migration weg vom Community-Projekt ingress-nginx hin zur Gateway API. Wichtig: Das abgekündigte Community-Projekt ingress-nginx ist nicht identisch mit F5s NGINX Ingress Controller, der in der Advisory separat gelistet ist – CVE und EOL schieben denselben Hebel: die Edge-Schicht ist kein „set and forget“.
Für Plattform-Teams in DACH heißt das praktisch: Image-Tags und Helm-Charts der Ingress-Controller in allen Clustern prüfen, auf verfügbare Fixed Builds je Downstream-Produkt achten, Config-Repos auf Regex-Maps mit nummerierten Captures greppen und den Patch-Pfad priorisieren, bevor ein öffentlicher Exploit den Zeitdruck erhöht. Stand 20. Juli 2026 lag die CVE nicht im CISA-KEV-Katalog und es war kein öffentlicher PoC bekannt. The Hacker News und Research kündigten eine verzögerte PoC-Freigabe an. Der verwandte Engine-Fall CVE-2026-42945 (in der Community als Rift geführt) hatte gezeigt, wie schnell aus Disclosure aktive Ausnutzung werden kann.
Was bricht, was trägt – und was Teams jetzt tun
- Klare Fixes: Open Source 1.30.4 / 1.31.3, Plus 37.0.3.1 (bzw. R36 P7 laut Orca/THN)
- Temporäre Mitigation: Regex-Maps auf named Captures umstellen – deckt den Hauptpfad ab
- Inventar ist machbar: enges Config-Muster, greppbar und scanner-fähig
- Downstream-Produkte (Ingress/Gateway/WAF) brauchen eigene Patched Builds – Core-Upgrade allein reicht oft nicht
- Named-Capture-Mitigation schließt laut Independent Research nicht jeden Nebenpfad
- RCE-Bewertung divergiert: F5 konservativ (ASLR), einzelne Reporter schärfer – Teams sollten worst-case patchen
F5 und Security-Research nennen zwei weitere CVEs aus derselben Patch-Welle (Orca: high CVSS; nginx.org stuft sie als medium): CVE-2026-60005 (uninitialisierter Memory-Disclosure im Slice-Modul) und CVE-2026-56434 (Use-after-free im SSI-Modul mit bestimmten Proxy-Settings). Für CVE-2026-56434 gibt es laut Orca keine Workaround-Alternative – nur Patch. Wer NGINX breit im Portfolio hat, plant also einen gebündelten Upgrade-Sprint, nicht drei Einzel-Tickets.
Die operative Checkliste bleibt kurz und hart:
- Versionen und Images: Core, Plus, Ingress Controller, Gateway Fabric, App Protect, Instance Manager gegen verfügbare Fixed Builds legen. Für noch ungepatchte Release-Linien Hersteller-Mitigation und Support-Status prüfen.
- Config-Scan: Regex-map plus nummerierte Captures ($1, $2) in String-Ausdrücken – Reporter-Scanner und eigene Greps über Includes.
- Mitigation nur als Brücke: named Captures, dann trotzdem Upgrade. „Upgrade ist der einzige vollständige Fix“ ist hier die belastbare Linie aus Research und Vendor-Changelog.
- Edge priorisieren: internet-facing Ingress und Shared Gateways vor internen Reverse Proxies.
Für Cloud-Architekten ist die Lektion größer als eine einzelne CVE. Die Edge-Schicht sammelt technische Schulden: abgekündigte Ingress-Controller, WAF-Sidecars, handgewachsene Map-Regeln aus zehn Jahren Traffic-Engineering. CVE-2026-42533 ist der Anlass, dieses Inventar sichtbar zu machen – und den Patch-Pfad zu testen, bevor der PoC den Kalender diktiert.
Häufige Fragen
Betrifft CVE-2026-42533 jeden NGINX-Server?
Nein. Die verwundbare Codebasis ist weit (0.9.6 bis 1.31.2), aber die Ausnutzung braucht eine spezifische Regex-map-Konfiguration mit Capture-Referenzen. Ohne dieses Muster bleibt der Server von diesem Overflow unberührt – Versions-Patching ist trotzdem der saubere Weg, weil Inventar und Config-Drift selten lückenlos sind.
Reicht ein Upgrade des Ingress-Controllers?
Nur wenn dort die gepatchte NGINX-Engine mitkommt und keine weiteren Plus-/WAF-/Gateway-Komponenten offen bleiben. F5 listet mehrere Downstream-Produkte. Cluster-Teams sollten Image-Tags, Helm-Charts und Manager-Instanzen gemeinsam prüfen, nicht nur den Controller-Deployment-Namen.
Ist Remote Code Execution realistisch?
F5 knüpft RCE an deaktiviertes oder umgehbares ASLR und bewertet die Angriffskomplexität als hoch. Unabhängige Researcher argumentieren schärfer und sehen in der Capture-Clobbering-Logik selbst einen Leak-Pfad. Solange kein öffentlicher PoC vorliegt, bleibt DoS der klar belegte Impact – für die Priorisierung gilt trotzdem: Edge patchen, bevor Exploit-Code zirkuliert.
Lesetipps der Redaktion
cloudmagazinArgo-CD-Lücke: 18 Monate offen, Cluster-ÜbernahmecloudmagazinIngress-NGINX ist abgekündigt: Der Weg zur Gateway APIcloudmagazinAcht Minuten bis AWS-Admin: offener S3-Bucket als LeckMehr aus dem MBF Media Netzwerk
MyBusinessFutureBaupreise +5 Prozent: Capex neu rechnenDigital ChiefsWelche Steuerung bleibt nach dem Agenten-RolloutSecurityTodayCyberresilienz: APIs und Patch-Fenster steuernBildquelle: KI-generiert (Juli 2026)
