NGINX CVE-2026-42533: Heap Buffer Overflow durch Capture-Variablen-Reihenfolge in map/regex — Patch-Pflicht für Kubernetes-Ingress

TL;DR — 90 Sekunden

Betroffen?

Nur Konfigurationen, die eine map-Direktive mit regex-Matching verwenden UND in einem String-Ausdruck zuerst die nummerierten Capture-Variablen ($1, $2 …) referenzieren, bevor die Ausgabevariable der Map selbst referenziert wird. Nicht jede NGINX-Instanz ist automatisch betroffen — es kommt auf das konkrete Konfigurationsmuster an.

Risiko?

Heap-Buffer-Overflow (CWE-122), CVSSv4 9.2 Critical / CVSSv3.1 8.1 High. Denial-of-Service über Worker-Crash ist zuverlässig reproduzierbar bestätigt. Remote Code Execution über ASLR-Bypass gilt als plausibel, ist aber öffentlich noch nicht demonstriert — Stand 22.07.2026 kein öffentlicher PoC, kein Eintrag im CISA-KEV-Katalog.

Sofortmaßnahme?

Konfigurationen auf regex-map-Blöcke mit nummerierten Captures prüfen. Wo ein Upgrade nicht sofort möglich ist, nummerierte Captures auf benannte Captures ((?<name>...)) umstellen — diese sind von der Ordering-Lücke nicht betroffen.

Empfehlung?

Auf NGINX 1.31.3 (Mainline), 1.30.4 (Stable) bzw. NGINX Plus 37.0.3.1 patchen. Bei Kubernetes-Ingress: Core-Engine, Ingress Controller, Gateway Fabric, App Protect und Instance Manager einzeln auf den Patch-Stand prüfen — das Patchen des Controllers allein reicht nicht, wenn die eingebettete NGINX-Engine ungepatcht bleibt.

Kritikalität?

Hoch. Die CVSS-Bewertung ist Critical, die Angriffsfläche in Kubernetes-Ingress-Umgebungen ist groß, und der DoS-Pfad ist zuverlässig reproduzierbar — das rechtfertigt hohe Priorität im laufenden Patch-Zyklus. Wir stufen nicht als „Kritisch mit aktiver Ausnutzung“ ein, weil RCE bislang unbewiesen ist und kein öffentlicher Exploit-Code kursiert; diese Unterscheidung ist wichtig für eine saubere Priorisierung.

 

Was ist das Problem?

Um den Bug zu verstehen, muss man wissen, wie NGINX map-Blöcke mit regex-Matching intern auswertet. Eine map-Direktive mit regulären Ausdrücken wird nicht in einem einzigen Durchlauf ausgewertet, sondern in zwei Pässen: Im ersten Pass ermittelt NGINX, welcher regex-Eintrag der Map matcht, und legt die daraus resultierenden Capture-Variablen ($1, $2, …) sowie die Länge des benötigten Ausgabepuffers fest. In einem zweiten Pass wird der Ausgabewert tatsächlich in den zuvor allozierten Puffer geschrieben.

Das Problem entsteht, wenn ein String-Ausdruck — etwa in einer log_format-Direktive, einem proxy_set_header oder einer weiteren map — zuerst die nummerierten Capture-Variablen der Map referenziert und erst danach die Ausgabevariable der Map selbst. In diesem Fall wertet NGINX zwischen den beiden Pässen den regulären Ausdruck der Map intern erneut aus, um die Capture-Variablen für die Verwendung im String-Ausdruck bereitzustellen. Diese Zweitauswertung überschreibt jedoch denselben Capture-State, den der erste Pass bereits zur Bestimmung der Pufferlänge verwendet hat — und zwar mit potenziell anderen Werten, wenn der Request so gestaltet ist, dass der interne Re-Match ein längeres oder anders strukturiertes Ergebnis liefert. Die Konsequenz: Der im ersten Pass allozierte Puffer ist zu klein für das, was im zweiten Pass tatsächlich geschrieben wird — und sowohl die Länge als auch der Inhalt des Overflows stehen unter der Kontrolle des anfragenden Clients, weil beides von den Werten im HTTP-Request abhängt, gegen die die Regex matcht.

F5 klassifiziert die Schwachstelle in der begleitenden Advisory (K000162097) unter CWE-122 (Heap-based Buffer Overflow) und bewertet sie mit CVSSv4 9.2 (Critical) bzw. CVSSv3.1 8.1 (High); dieselbe Fundstelle wurde parallel im offiziellen CVE-Record (cve.org/CVE-2026-42533) registriert. Bemerkenswert an der Historie: Der zugrunde liegende map-Auswertungsmechanismus existiert unverändert seit NGINX 0.9.6 — die Lücke ist also im Kern eine seit rund 15 Jahren im Code schlummernde Race-Bedingung zwischen zwei Auswertungspässen, die erst jetzt systematisch nachgewiesen wurde.

Wer ist betroffen?

Die entscheidende Einschränkung zuerst: CVE-2026-42533 betrifft nicht automatisch jede NGINX-Instanz auf dem Planeten. Ausnutzbar ist die Lücke ausschließlich dort, wo (a) eine ungepatchte NGINX-Version im Einsatz ist UND (b) die Konfiguration tatsächlich eine map-Direktive mit regex-Matching enthält, deren Ausgabe in einem String-Ausdruck verwendet wird, der zuerst die nummerierten Capture-Variablen und erst danach die Map-Ausgabevariable referenziert. Wer NGINX ausschließlich als einfachen Static-File- oder Reverse-Proxy-Server ohne regex-map-Konstrukte betreibt, ist von diesem konkreten CVE nicht direkt betroffen — sollte aber trotzdem patchen, weil regex-map-Konstrukte häufig nachträglich durch Ops-Teams, Helm-Charts oder Third-Party-Module eingeführt werden, ohne dass das allen Beteiligten bewusst ist.

Wichtig für Kubernetes-Betreiber: NGINX Ingress Controller, Gateway Fabric, App Protect WAF und Instance Manager sind separate Produkte mit eigenen Release-Zyklen, die aber alle dieselbe NGINX-Engine unter der Haube einbetten. Ein gepatchter Ingress-Controller-Release hilft nichts, wenn das darin gebündelte NGINX-Binary selbst nicht auf 1.31.3/1.30.4 aktualisiert wurde — deshalb muss der Patch-Stand für jede Komponente einzeln verifiziert werden, nicht pauschal über die Versionsnummer des umgebenden Produkts.

Auswirkungen

Zwei Auswirkungsebenen sind sauber zu trennen, weil sie unterschiedlich gut belegt sind.

Denial of Service (bestätigt, zuverlässig reproduzierbar): Ein Request, der die verwundbare map/regex-Konstellation triggert, überschreibt Heap-Speicher jenseits des allozierten Puffers und bringt den betroffenen NGINX-Worker-Prozess zum Absturz. Da NGINX Worker-Prozesse bei einem Crash typischerweise vom Master-Prozess neu gestartet werden, führt ein einzelner Request in der Regel „nur“ zu kurzzeitigen Verbindungsabbrüchen für Clients, die zufällig denselben Worker nutzen — ein Angreifer, der wiederholt crash-auslösende Requests sendet, kann daraus aber einen anhaltenden Verfügbarkeitsausfall konstruieren. Dieser Pfad gilt als praktisch erwiesen und benötigt keine besonderen Vorkenntnisse über das interne Speicherlayout der Zielinstanz.

Remote Code Execution (plausibel, öffentlich nicht demonstriert): Nach sekundärer Berichterstattung hat ein Sicherheitsforscher namens Stan Shaw behauptet, dieselbe Schreib-Primitive lasse sich über einen einzelnen unauthentifizierten GET-Request zweckentfremden, um Speicheradressen aus dem Prozessraum zu leaken und damit ASLR (Address Space Layout Randomization) zu umgehen — ein klassischer erster Schritt auf dem Weg zu einer vollständigen Remote-Code-Execution-Kette. Diese Behauptung ist technisch nicht unplausibel, weil eine kontrollierbare Heap-Overflow-Schreib-Primitive grundsätzlich für Speicher-Leaks und Kontrollfluss-Manipulation missbraucht werden kann. Zum Zeitpunkt dieses Artikels (22.07.2026) ist CVE-2026-42533 jedoch nicht im CISA-KEV-Katalog (Known Exploited Vulnerabilities) gelistet, es liegt kein öffentlicher Proof-of-Concept vor, und Forscher haben eine „verzögerte PoC-Veröffentlichung“ angekündigt, um Betreibern Zeit zum Patchen zu geben. Wir behandeln den RCE-Pfad deshalb als glaubwürdig, aber unbewiesen — eine Unterscheidung, die für die Priorisierung im eigenen Patch-Management wichtig ist: Sie rechtfertigt hohe Dringlichkeit, aber keine Panik-Kommunikation mit „aktiv ausgenutzte RCE“-Framing, solange kein Nachweis vorliegt.

Mitigation / Sofortmaßnahmen

Upgrade auf die gepatchte Version

Der einzige vollständige Fix ist das Upgrade auf NGINX 1.31.3 (Mainline), 1.30.4 (Stable) oder NGINX Plus 37.0.3.1. Für Debian/Ubuntu mit dem offiziellen nginx.org-Repository:

# Paketquellen aktualisieren und auf die gepatchte Version heben
sudo apt update
sudo apt install --only-upgrade nginx
# Version verifizieren
nginx -v

Falls das offizielle nginx.org-Repository noch nicht eingebunden ist:

sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring
curl nginx.org/keys/nginx_signing.key | gpg --dearmor \
  | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
nginx.org/packages/debian $(lsb_release -cs) nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update && sudo apt install nginx

Für RHEL/CentOS/Rocky/Alma mit dem offiziellen nginx.org-Repository:

sudo yum install yum-utils
sudo tee /etc/yum.repos.d/nginx.repo > /dev/null <<'EOF'
[nginx-stable]
name=nginx stable repo
baseurl=https://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
EOF
sudo yum update nginx

Für Docker-basierte Deployments: Image-Tag auf eine Variante bumpen, die 1.31.3 bzw. 1.30.4 bündelt, und den Build-Kontext neu bauen statt nur den laufenden Container neu zu starten — der Fix liegt im Binary, nicht in der Laufzeit-Konfiguration:

# Beispiel: expliziten, gepinnten Tag statt "latest" verwenden
docker pull nginx:1.30.4
# In Kubernetes-Manifesten/Helm-Values entsprechend die Image-Referenz aktualisieren
# und einen Rolling-Restart der betroffenen Deployments auslösen

Stopgap: nummerierte auf benannte Captures umstellen

Wo ein sofortiges Upgrade organisatorisch nicht möglich ist, lässt sich die konkrete Auslösebedingung als Übergangsmaßnahme entschärfen: Benannte Capture-Gruppen ((?<name>...)) sind von der beschriebenen Ordering-Lücke nicht betroffen, weil sie nicht über den gemeinsam genutzten nummerierten Capture-State laufen, der zwischen den beiden Auswertungspässen überschrieben wird.

# Vorher (potenziell betroffenes Muster):
map $http_x_forwarded_for $client_zone {
    ~^(?P<ip>\d+\.\d+\.\d+\.\d+)$ zone_$1;
}
# String-Ausdruck referenziert $1 VOR $client_zone -> verwundbares Muster

# Nachher (Stopgap-Mitigation):
map $http_x_forwarded_for $client_zone {
    ~^(?P<ip>\d+\.\d+\.\d+\.\d+)$ zone_$client_zone;
}
# Referenz auf die Map-Ausgabevariable statt auf die nummerierte Capture-Variable

Diese Umstellung ist ausdrücklich eine Übergangslösung, kein Ersatz für den Versions-Patch — sie schließt nur das konkrete Auslösemuster, nicht die zugrunde liegende Code-Schwäche im map-Auswertungsmechanismus selbst.

Kubernetes-Ingress-Checkliste

• Core-Engine, NGINX Plus, Ingress Controller, Gateway Fabric, App Protect WAF und Instance Manager einzeln gegen die jeweils gepatchten Build-Stände abgleichen — das Patchen des Ingress Controllers allein hilft nur, wenn auch die darin gebündelte NGINX-Engine selbst gepatcht ist.
• Alle Ingress-/Gateway-Konfigurationen (inklusive Annotations, die intern map-Blöcke generieren) auf regex-map-Muster mit nummerierten Captures durchsuchen.
• Als Sofortmaßnahme nummerierte auf benannte Captures umstellen, danach regulär auf den Patch-Stand heben.
• Internet-exponierte Ingress-Controller und geteilte Gateways zuerst patchen — dort ist die Angriffsfläche am größten und die Blast-Radius-Wirkung am höchsten, weil ein einzelner Ingress oft Traffic für viele Namespaces/Mandanten terminiert.
• Bei Nutzung des Community-Projekts kubernetes/ingress-nginx (EOL seit März 2026, letzte Version 1.15.1): kein offizieller OSS-Patch mehr zu erwarten — Migration auf eine aktiv gepflegte Alternative oder ein kommerziell gepflegtes Drop-in-Image separat einplanen.

Detection / Prüfung

Laufende NGINX-Version prüfen

# Kompilierte Version und Build-Flags anzeigen
nginx -V
# Kurzform der Versionsnummer
nginx -v

Prüfen, ob die ausgegebene Version kleiner als 1.30.4 (Stable-Zweig) bzw. kleiner als 1.31.3 (Mainline-Zweig) ist, oder bei NGINX Plus kleiner als 37.0.3.1.

Konfiguration auf das verwundbare Muster durchsuchen

# Alle map-Blöcke mit regex-Matching auflisten
grep -rn "map \$" /etc/nginx/ | grep -E "~"
# Gezielt nach nummerierten Capture-Referenzen suchen,
# die im selben Konfigurationsbereich wie eine regex-map vorkommen
grep -rn '\$[0-9]' /etc/nginx/

Die grep-Suche liefert Kandidaten, ersetzt aber keine manuelle Prüfung: Entscheidend ist, ob ein String-Ausdruck $1/$2 referenziert, bevor er die Ausgabevariable derselben map referenziert — das lässt sich nicht zuverlässig automatisiert erkennen, sondern erfordert eine Durchsicht jeder Fundstelle im Kontext. Mehrere Anbieter haben laut Sekundärberichten mittlerweile statische Konfigurations-Scanner veröffentlicht, die genau dieses Reihenfolge-Muster erkennen; für den eigenen Bestand empfiehlt sich, ein solches Tool zusätzlich zur manuellen Sichtung einzusetzen, sobald ein vertrauenswürdiges verfügbar ist.

Kubernetes: Image-Versionen der Ingress-Komponenten prüfen

# Image-Referenzen aller Pods im ingress-nginx-Namespace auflisten
kubectl get pods -n ingress-nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

# Tatsächliche NGINX-Version innerhalb eines laufenden Controller-Pods abfragen
kubectl exec -n ingress-nginx <pod-name> -- nginx -V

# Image-Tags aller Deployments im Cluster nach nginx-bezogenen Images filtern
kubectl get deployments -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i nginx

Diese Befehle folgen dem Standard-kubectl-Muster zur Image- und Versionsermittlung; die exakte Ausgabe hängt vom jeweiligen Ingress-Controller-Deployment ab (Namespace- und Container-Namen können abweichen), daher als Ausgangspunkt und nicht als Copy-Paste-Garantie für jede Installation verstehen.

Betreiberempfehlung

Operative Entscheidungshilfe:

• Heute handeln, wenn: Ein internetseitig exponierter NGINX-Ingress terminiert Traffic für produktive Systeme UND die Konfiguration regex-map-Konstrukte mit nummerierten Captures enthält (oder deren Abwesenheit nicht sicher verifiziert ist).
• Im nächsten regulären Patch-Zyklus, wenn: Die laufende NGINX-Version ungepatcht ist, aber eine Konfigurationsprüfung keine verwundbaren regex-map-Muster im Request-Pfad ergeben hat — trotzdem zeitnah patchen, weil sich Konfigurationen ändern.
• Nur verifizieren, wenn: Bereits auf 1.31.3/1.30.4/Plus 37.0.3.1 gepatcht — hier reicht eine Bestandsaufnahme, um sicherzustellen, dass wirklich alle Instanzen (inklusive Ingress Controller, Gateway Fabric, App Protect, Instance Manager) den Patch-Stand erreicht haben.

Für Mittelstands-Betriebe

Wer NGINX als klassischen Reverse-Proxy oder Loadbalancer vor einer überschaubaren Zahl von Anwendungen betreibt, hat in der Regel eine kleine, gut überschaubare Konfigurationsbasis — das macht die manuelle Prüfung auf regex-map-Muster in ein bis zwei Stunden machbar. Der pragmatische Weg: Zunächst patchen (Upgrade ist der vollständige Fix und in den meisten Fällen risikoärmer als eine manuelle Konfigurationsänderung), danach in Ruhe die Konfiguration auf das Muster durchsehen, um zu verstehen, ob man überhaupt exponiert war. Ich rate explizit davon ab, Upgrade und Konfigurationsprüfung gegeneinander auszuspielen — beides gehört in denselben Wartungsfenster-Slot.

Für Enterprise-Umgebungen

Größere Umgebungen mit vielen NGINX-Instanzen unter unterschiedlicher Verantwortung (verschiedene Teams, verschiedene Deployment-Pipelines, teils Legacy-Configs, die niemand mehr im Detail kennt) sollten das CVE als Anlass nehmen, ein zentrales Inventar aller NGINX-basierten Komponenten aufzubauen oder zu aktualisieren — inklusive NGINX Plus, App Protect WAF und Instance Manager, nicht nur Open-Source-Instanzen. Ohne ein solches Inventar bleibt „sind wir betroffen?“ eine Frage, die Wochen statt Stunden zur Beantwortung braucht. Priorisierung nach Internet-Exposition und nach geschäftlicher Kritikalität der dahinterliegenden Systeme, nicht nach alphabetischer Reihenfolge der Hostnamen.

Für Kubernetes-Betreiber

Hier ist die Dringlichkeit strukturell höher, weil ein einzelner Ingress-Controller oft Traffic für viele Namespaces und Mandanten terminiert — ein erfolgreicher DoS gegen den Ingress wirkt sich nicht auf eine Anwendung aus, sondern potenziell auf den gesamten Cluster-Traffic. Wer noch das EOL-Community-Projekt kubernetes/ingress-nginx in Version 1.15.1 einsetzt, sollte die fehlende offizielle Patch-Verfügbarkeit als zusätzlichen Dringlichkeitsfaktor werten und parallel zur kurzfristigen Config-Mitigation eine mittelfristige Migrationsentscheidung treffen (gepflegter Fork, kommerzielles Drop-in-Image oder Wechsel auf eine andere Ingress-/Gateway-Implementierung). In eigenen FrankenPHP/Kubernetes-Deployments für TYPO3-Betrieb setze ich seit einiger Zeit bewusst auf schlankere, gut gepflegte Ingress-Alternativen mit kleinerer Angriffsfläche — dieses CVE ist ein weiterer Datenpunkt dafür, warum sich diese Entscheidung aus meiner Sicht auszahlt.

Was ich konkret getan habe

Auch wenn NGINX in meinem eigenen produktiven Stack für TYPO3-Hosting inzwischen größtenteils durch FrankenPHP/Caddy ersetzt ist, betreue ich weiterhin Bestandskunden und Alt-Setups, in denen NGINX im Anfrage-Pfad liegt — deshalb war CVE-2026-42533 für mich kein rein theoretisches Advisory. Nach Bekanntwerden habe ich zunächst ein Image-Digest-Inventar aller NGINX-basierten Container-Images über meine eigene Betriebsfläche gezogen — feste Tags allein sagen zu wenig, weil „nginx:stable“ heute etwas anderes referenzieren kann als vor zwei Wochen, und ich will bei einem CVE wie diesem genau wissen, welches Binary in welcher Umgebung tatsächlich läuft. Parallel habe ich meine eigenen und die kundenseitig verwalteten NGINX-Konfigurationen mit einer gezielten grep-Suche nach regex-map-Blöcken durchsucht — mit dem erwarteten Ergebnis, dass die meisten Konfigurationen gar keine map-Direktive mit regex-Matching verwenden, aber zwei Alt-Configs mit einem WAF-Bypass-Workaround aus 2023 genau in dieses Muster fielen. Diese wurden vorrangig auf benannte Captures umgestellt, während der reguläre Versions-Patch für den nächsten planmäßigen Wartungsslot vorgemerkt wurde. Zusätzlich habe ich meine eigene Internet-Adressraum-Übersicht (extern erreichbare IPs/Domains) gegen den Fingerprint „NGINX-Server-Header ohne aktuellen Patch-Stand“ gescannt, um sicherzugehen, dass keine vergessene Instanz übersehen wird — eine Disziplin, die sich bei praktisch jedem größeren Advisory der letzten Jahre ausgezahlt hat, weil „vergessene“ Instanzen fast immer die sind, die am längsten ungepatcht bleiben.

Fazit

CVE-2026-42533 ist ein Lehrstück dafür, wie eine seit 15 Jahren im Code liegende Zwei-Pass-Auswertungslogik unter der richtigen Kombination aus Konfigurationsmuster und Angreifer-kontrolliertem Input zu einem Critical-CVSS-Advisory werden kann. Die gute Nachricht: Die Schwachstelle ist konfigurationsabhängig, nicht universell — wer keine regex-map mit vorgezogenen nummerierten Captures verwendet, ist über diesen spezifischen Pfad nicht angreifbar. Die schlechte Nachricht: Genau dieses Muster taucht in der Praxis überraschend häufig in gewachsenen WAF-Workarounds, Header-Normalisierungen und Multi-Tenant-Routing-Logik auf — und wer es nicht gezielt sucht, findet es nicht zufällig. Für Kubernetes-Betreiber kommt hinzu, dass die betroffene Engine tief in mehreren Ingress- und Gateway-Produkten eingebettet ist, sodass ein vollständiges Bild nur durch komponentenweise Versionsprüfung entsteht. DoS ist bestätigt und reproduzierbar, RCE ist plausibel, aber (Stand 22.07.2026) unbewiesen — diese Unterscheidung sauber zu kommunizieren ist genauso wichtig wie das Patchen selbst, weil Panik-Framing bei der nächsten, tatsächlich aktiv ausgenutzten Lücke die eigene Glaubwürdigkeit kostet.

Quellen

• CVE-2026-42533 — offizieller CVE-Record (cve.org) — Primärquelle für CVE-Zuordnung, Beschreibung und Referenzen.
• F5 Knowledge Base Artikel K000162097 — offizielle Advisory mit CVSS-Bewertungen, betroffenen und gepatchten Versionen.
• nginx.org Security Advisories — offizielle Übersicht der NGINX-Versionsstände zu CVE-2026-42533 (betroffen 0.9.6–1.31.2, behoben ab 1.31.3/1.30.4).
• HeroDevs: CVE-2026-42533 und EOL Ingress-NGINX — Einordnung der Auswirkungen auf das EOL-Community-Projekt kubernetes/ingress-nginx.
• The Hacker News: Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution — Sekundärberichterstattung zur RCE-Einordnung und ASLR-Bypass-Behauptung.