Die Schwachstelle CVE-2026-42533 entsteht durch eine inkonsistente Verarbeitung von Regex-Captures in der zweistufigen Script Engine von NGINX. Dadurch kann ein Heap Buffer Overflow ausgelöst werden, der einen Denial of Service oder unter bestimmten Voraussetzungen sogar die Ausführung von beliebigem Code ermöglicht.
F5 hat am 15. Juli 2026 in NGINX 1.30.4 (Stable), 1.31.3 (Mainline) sowie in NGINX Plus R37 P3 (Version 37.0.3.1) eine kritische Sicherheitslücke (CVE-2026-42533) geschlossen. Diese ermöglicht es einem nicht authentifizierten Angreifer, mithilfe speziell präparierter HTTP-Anfragen einen Heap-Buffer-Overflow im Worker-Prozess auszulösen. Die Schwachstelle entsteht durch eine inkonsistente Verarbeitung von Regex-Captures in der zweistufigen Script Engine von NGINX, wodurch unter bestimmten Voraussetzungen sogar die Ausführung von beliebigem Code möglich sein kann. Da die Schwachstelle aus der Ferne ohne Authentifizierung ausnutzbar ist und die Gefahr eines Denial-of-Service sowie potenziell einer Remote-Code-Ausführung besteht, sollten alle betroffenen NGINX-Installationen schnellstmöglich auf eine gepatchte Version aktualisiert werden.
Wie funktioniert die Lücke?
NGINX baut Strings aus Konfigurationsausdrücken, beispielsweise für Logging, Header oder Rewrites, in zwei Durchläufen auf. Im ersten Durchlauf wird der Ausdruck ausgewertet, um die benötigte Größe des Ergebnisses zu bestimmen. Anschließend reserviert NGINX einen Heap-Puffer mit exakt dieser Größe. Im zweiten Durchlauf wird derselbe Ausdruck erneut ausgewertet, um die eigentlichen Daten in den reservierten Puffer zu schreiben. Dieses Verfahren funktioniert nur dann korrekt, wenn beide Auswertungen auf identischen Daten basieren.
Die Schwachstelle tritt nur unter einer spezifischen Konfiguration auf. Voraussetzung hierfür ist die Verwendung einer map-Direktive mit regulären Ausdrücken. Zudem muss ein String-Ausdruck zunächst auf eine nummerierte Capture-Variable ($1, $2 usw.) aus einem zuvor ausgeführten regulären Ausdruck zugreifen und erst anschließend die von der map erzeugte Variable referenzieren. Nach Angaben von F5 kann derselbe Fehler unter bestimmten Bedingungen auch durch die Verwendung einer nicht cachebaren Variablen in einem String-Ausdruck ausgelöst werden.
Die Ursache liegt darin, dass NGINX die Ergebnisse von Regex-Captures nicht für jeden Ausdruck separat speichert, sondern einen gemeinsamen Speicherbereich wiederverwendet. Während des ersten Durchlaufs wird beispielsweise $1 aus einem ursprünglichen regulären Ausdruck, etwa einem location-Match, gelesen und zur Berechnung der erforderlichen Puffergröße verwendet. Bevor der zweite Durchlauf beginnt, wertet NGINX jedoch den regulären Ausdruck der map-Direktive aus. Dabei werden die zuvor gespeicherten Capture-Werte im gemeinsamen Speicher überschrieben.
Im anschließenden Schreibdurchlauf greift NGINX erneut auf $1 zu, erhält jedoch nicht mehr den ursprünglichen Capture-Wert, sondern den durch die map-Auswertung überschriebenen Inhalt. Ist dieser neue Capture-Wert länger als der ursprünglich berücksichtigte, schreibt NGINX mehr Daten in den Puffer, als dieser aufnehmen kann. Dadurch entsteht ein Heap-Buffer-Overflow. Sowohl die Länge als auch der Inhalt der über den Puffer hinaus geschriebenen Daten können durch eine präparierte HTTP-Anfrage beeinflusst werden. Die Schwachstelle lässt sich daher ohne Authentifizierung aus der Ferne auslösen, sofern die betroffene Konfiguration vorliegt.
Die Auswirkungen reichen mindestens bis zu einem Denial-of-Service. Der Heap-Buffer-Overflow führt zum Absturz beziehungsweise Neustart des betroffenen NGINX-Worker-Prozesses. Darüber hinaus hält F5 eine Remote-Code-Ausführung für möglich, wenn Address Space Layout Randomization (ASLR) deaktiviert ist oder anderweitig umgangen werden kann. Ein an der Offenlegung beteiligter Sicherheitsforscher argumentiert darüber hinaus, dass sich derselbe Fehler auch in umgekehrter Richtung ausnutzen lasse. Ist die überschriebene Capture kleiner als der ursprüngliche Wert, könne uninitialisierter Heap-Speicher ausgelesen werden. Die dabei gewonnenen Adressinformationen könnten eine Umgehung von ASLR ermöglichen und damit die Voraussetzungen für eine Remote-Code-Ausführung schaffen.
Quellen:
- https://thehackernews.com/2026/07/critical-nginx-vulnerability-can-crash.html
- https://my.f5.com/manage/s/article/K000162097
- https://security-tracker.debian.org/tracker/CVE-2026-42533
Erkennen und Handeln mit Enginsight
Prüfen Sie im Update Manager, ob ein Update für NGINX verfügbar ist. Dort wird Ihnen gleichzeitig die Anzahl der betroffenen Hosts angezeigt. Anschließend können Sie das Update entweder zentral für alle betroffenen Systeme gleichzeitig ausrollen oder die Hosts bei Bedarf einzeln und manuell aktualisieren.
