NGINX CVE-2026-42533: Wenn Regex-Captures den Speicherpuffer sprengen

Clara

20. Juli 2026 4 min read

NGINX CVE-2026-42533: Wenn Regex-Captures den Speicherpuffer sprengen

NGINX läuft in vielen Unternehmen nicht als sichtbare Anwendung, sondern als Infrastruktur im Hintergrund: Reverse Proxy vor APIs, Gateway zwischen Diensten, TLS-Endpunkt oder Baustein einer Plattform. Genau deshalb ist die neue Schwachstelle praktisch relevant. Ein Server kann eine verwundbare Version einsetzen, ohne automatisch angreifbar zu sein. Entscheidend ist eine bestimmte Kombination aus regulären Ausdrücken, map-Direktiven und Variablen. Wer nur Versionsnummern prüft, bekommt daher keine belastbare Risikoeinschätzung.

F5 und das NGINX-Projekt veröffentlichten CVE-2026-42533 am 15. Juli und schlossen die Lücke mit NGINX Open Source 1.30.4 sowie 1.31.3. Unter passenden Konfigurationsbedingungen kann ein nicht authentifizierter Angreifer mit präparierten HTTP-Anfragen einen Heap Buffer Overflow im Worker-Prozess auslösen. Die direkte Folge kann ein Worker-Neustart sein — und damit ein Denial of Service. F5 bewertet die Schwachstelle nach CVSS 4.0 mit 9,2 („Critical“), nach CVSS 3.1 mit 8,1 („High“).

Technische Ursache: Zwei Auswertungsdurchläufe, aber veränderlicher Zustand

Der Fehler steckt in der Script Engine von NGINX. Sie setzt zur Laufzeit Zeichenketten aus statischen Bestandteilen, Variablen und Regex-Captures wie $1 zusammen. Dafür nutzt NGINX zwei Durchläufe. Zuerst berechnet ein Längen-Durchlauf, wie groß der benötigte Puffer sein muss. Danach reserviert NGINX genau diesen Speicher. Im zweiten Durchlauf schreibt die Engine die tatsächlichen Daten hinein.

Dieses Verfahren funktioniert nur, wenn beide Durchläufe denselben Zustand sehen. Bei CVE-2026-42533 ist genau das nicht garantiert. Regex-Treffer landen in einem gemeinsam genutzten Capture-Zustand der Anfrage. Wird zwischen zwei Variablenzugriffen eine regexbasierte map-Variable ausgewertet, kann deren Match die zuvor gespeicherten Capture-Positionen überschreiben. Der erste Durchlauf misst dann etwa einen kurzen Wert. Der zweite schreibt einen längeren, vom Angreifer beeinflussbaren Wert. Der reservierte Puffer ist zu klein; Daten laufen über sein Ende hinaus.

Der offizielle CVE-Datensatz nennt zwei relevante Varianten: eine map-Direktive mit Regex-Matching, bei der ein String-Ausdruck Capture-Variablen vor der Ausgabevariable der Map referenziert, sowie bestimmte Konstellationen mit nicht cachebaren Variablen. Der Fehler betrifft den Datenpfad, nicht die NGINX-Kontrollebene. Er ist also über normale Anfragen erreichbar, sofern die anfällige Konfiguration vorhanden ist.

Betroffene Versionen und belastbare Fakten

Nach dem von F5 gepflegten CVE-Eintrag sind NGINX-Open-Source-Versionen ab 0.9.6 bis vor 1.30.4 sowie 1.31.2 bis vor 1.31.3 betroffen. Für NGINX Plus nennt der Datensatz mehrere verwundbare Release-Linien; unter anderem ist 37.0 vor 37.0.3.1 betroffen. Das offizielle NGINX-Changelog bestätigt die Korrektur in 1.31.3 und erwähnt neben der regexbasierten map-Konstellation ausdrücklich die ähnliche Variante mit einer nicht cachebaren Variablen.

Die Schwachstelle erfordert keine Anmeldung und keine Benutzerinteraktion, wird aber mit hoher Angriffskomplexität bewertet. F5 nennt Codeausführung für Systeme, auf denen Address Space Layout Randomization deaktiviert ist oder umgangen werden kann. Der Sicherheitsforscher Stan Shaw, einer der unabhängigen Melder, geht weiter: In Tests auf Ubuntu 24.04 habe eine umgekehrte Größenabweichung uninitialisierte Heap-Daten offengelegt und damit Adressen geliefert, die einen ASLR-Bypass ermöglichten. Shaw berichtet von zehn erfolgreichen Durchläufen in zehn Tests, hält den vollständigen Exploit aber zunächst zurück.

Diese Aussage ist relevant, ersetzt aber keine unabhängig bestätigte allgemeine Exploit-Garantie. F5 formuliert vorsichtiger. Ein öffentlich überprüfbarer Proof of Concept für vollständige Codeausführung lag zum Recherchezeitpunkt nicht vor. Auch der CISA-Katalog der nachweislich ausgenutzten Schwachstellen führte CVE-2026-42533 am 20. Juli nicht. Belastbare öffentliche Hinweise auf aktive Ausnutzung gibt es damit nicht.

Warum der Fall über einen einzelnen NGINX-Patch hinausgeht

CVE-2026-42533 ist bereits der dritte binnen kurzer Zeit veröffentlichte Heap-Overflow im Umfeld der zweiphasigen NGINX-Auswertung. Die konkreten Trigger unterscheiden sich. Das strukturelle Muster ist ähnlich: Der Längen-Durchlauf trifft eine Annahme über den späteren Schreibvorgang, obwohl sich der zugrunde liegende Anfragezustand während der Auswertung verändern kann.

Für Plattform- und DevSecOps-Teams ist das ein klares Signal: Konfiguration ist ein ausführungsrelevantes Artefakt. Eine sichere Binärdatei kann durch eine bestimmte Kombination legitimer Direktiven exponiert werden. Umgekehrt ist nicht jede Instanz einer betroffenen Version unmittelbar ausnutzbar. Klassische Schwachstellen-Scanner, die nur Paketstände erfassen, können dieses Risiko deshalb überzeichnen oder falsch priorisieren.

Dazu kommt die breite Verteilung von NGINX in Unternehmen. Die Software läuft nicht nur auf klassischen Webservern. Sie steckt auch in Container-Images, Appliances, Ingress- und Gateway-Produkten. Ein Update des Betriebssystempakets reicht nicht, wenn Kubernetes-Images, Golden Images oder eingebettete Komponenten unverändert bleiben.

Konkrete Implikationen für Unternehmen

Erstens sollten Betreiber auf NGINX Open Source 1.30.4 beziehungsweise 1.31.3 aktualisieren — oder auf einen NGINX-Plus-Stand, den der Hersteller als korrigiert ausweist. Ein geordnetes Rollout mit Health Checks ist sinnvoller als ein hektischer Austausch ohne Rückfallplan. Ein Worker-Neustart durch einen Angriff ist ein Problem. Ein ungeprüftes Gateway-Update kann aber ebenfalls Produktionsverkehr stören.

Zweitens gehört eine gezielte Konfigurationsprüfung in die Priorisierung. Teams sollten regexbasierte map-Blöcke suchen sowie Ausdrücke, in denen Regex-Captures aus location, server_name, rewrite oder if zusammen mit einer später ausgewerteten Map-Variable vorkommen. Der Forscher hat dafür einen statischen Scanner veröffentlicht, der Includes verfolgt und die Reihenfolge prüft. Solche Werkzeuge sollten nur auf Kopien der Konfiguration oder in einer kontrollierten CI-Pipeline laufen. Treffer müssen anschließend manuell validiert werden.

Drittens sollten Teams nicht nur direkt nebeneinander stehende Variablen prüfen. Laut technischer Analyse kann die problematische Reihenfolge auch über mehrere Direktiven desselben Blocks entstehen, etwa bei verschiedenen proxy_set_header-Anweisungen. Relevante Konfigurationen gehören deshalb als Ganzes in die Analyse.

Viertens ist Monitoring angebracht. Unerklärliche Worker-Neustarts, Segmentation Faults, Spitzen bei HTTP 500 und ungewöhnliche Requests an regexbasierte Routen sollten untersucht werden. Das beweist keinen Angriff. Es erhöht aber die Chance, Exploit-Versuche oder instabile Konfigurationen früh zu erkennen.

Risiken und Limitierungen

Der CVSS-Wert allein ist keine Expositionsanalyse. Die Version muss betroffen sein. Die Konfiguration muss den fehlerhaften Auswertungspfad erzeugen. Und zuverlässige Codeausführung ist deutlich anspruchsvoller als ein Absturz. Auch die von Shaw beschriebene ASLR-Umgehung basiert bislang auf seinen Tests und ist nicht öffentlich vollständig reproduzierbar.

Als Übergang kann das Ersetzen nummerierter Captures durch sauber getrennte, benannte Variablen bestimmte Pfade entschärfen. Shaw beschreibt jedoch eine engere Variante mit kollidierenden benannten Capture-Gruppen. Konfigurationsumbau ist daher keine gleichwertige Alternative zum Update. Die belastbare Maßnahme bleibt der Wechsel auf eine korrigierte Version.

Fazit

CVE-2026-42533 zeigt, warum moderne Infrastruktur-Sicherheit Versions-, Konfigurations- und Laufzeitsicht zusammenführen muss. Die Lücke ist kritisch, aber nicht pauschal auf jedem NGINX-System ausnutzbar. Unternehmen sollten deshalb weder abwarten noch jedes Gateway alarmistisch als kompromittiert behandeln.

Die richtige Reaktion ist konkret: betroffene Instanzen und eingebettete Images inventarisieren, auf korrigierte Releases aktualisieren, regexbasierte Map-Konfigurationen prüfen und Worker-Anomalien beobachten. Der wichtigste Lerneffekt reicht über NGINX hinaus: Wenn Software Speicher zuerst bemisst und später aus veränderlichem Zustand befüllt, kann eine scheinbar harmlose Konfigurationskombination zur Memory-Safety-Grenze werden.