Zum Inhalt springen

Kritische Nginx-Lücke CVE-2026-42533: Heap Overflow über präparierte HTTP-Anfragen

F5 hat am 15. Juli 2026 eine kritische Schwachstelle in Nginx geschlossen. Angreifer können ohne Anmeldung mit präparierten HTTP-Anfragen einen Heap Buffer Overflow im Worker-Prozess auslösen. Im Regelfall stürzt der Prozess ab und startet neu, was einen Denial of Service bedeutet. Ist der Speicherschutz ASLR deaktiviert oder lässt er sich umgehen, kann Schadcode auf dem System landen.

Die Lücke trägt die Kennung CVE-2026-42533 und wird von F5 mit CVSS v4.0 auf 9.2 bewertet, auf der älteren Skala v3.1 mit 8.1. Nginx selbst stuft sie als „major“ ein.

Wo das Problem sitzt

Betroffen ist die Script-Engine von Nginx, also der Teil, der zur Laufzeit Zeichenketten aus Direktiven zusammensetzt. Die Auswertung läuft in zwei Durchgängen: Der erste misst, wie viele Bytes das Ergebnis braucht, und reserviert den Puffer. Der zweite schreibt die Bytes hinein.

Die Lücke entsteht, wenn eine map-Direktive mit Regex-Matching arbeitet und eine String-Expression zuerst die Capture-Variablen eines vorherigen Regex-Treffers und erst danach die Ausgabevariable der Map referenziert. Zwischen den beiden Durchgängen wird der gemeinsame Capture-Zustand überschrieben. Der Puffer wird also für die ursprüngliche Capture dimensioniert, gefüllt wird er aber mit einer anderen, deren Länge der Angreifer bestimmt. Länge und Inhalt des Überlaufs kommen direkt aus der Anfrage, aus URI, Headern oder Body. Denselben Effekt kann unter bestimmten Bedingungen auch eine nicht cachefähige Variable in einer String-Expression auslösen.

Wichtig für die Risikobewertung: Nicht jeder Nginx-Server ist angreifbar. Die Ausnutzbarkeit hängt an der Konfiguration, nicht allein an der Version.

Betroffene Versionen

Verwundbar sind laut Nginx-Sicherheitsseite alle Versionen von 0.9.6 bis einschließlich 1.31.2. Der Fehler reicht damit bis 2011 zurück, als die map-Direktive Regex-Unterstützung bekam.

Behoben ist die Schwachstelle in Nginx 1.30.4 (Stable) und 1.31.3 (Mainline) sowie in NGINX Plus 37.0.3.1. F5 listet zusätzlich Nginx Ingress Controller, Gateway Fabric, App Protect WAF und Instance Manager als betroffen auf. Für diese vier Produkte lagen zum Zeitpunkt der Advisory-Veröffentlichung noch keine fertigen Builds vor. Im selben Update hat F5 außerdem CVE-2026-60005 im Slice-Modul und CVE-2026-56434 im SSI-Modul geschlossen.

Warum es eilt

F5 knüpft die Codeausführung an ein deaktiviertes oder umgehbares ASLR und lässt damit den Eindruck zu, es handle sich auf Standardsystemen um ein reines DoS-Problem. Der Sicherheitsforscher Stan Shaw, der unter dem Namen cyberstan veröffentlicht und zu den Meldern der Lücke gehört, widerspricht dem. Nach seiner Analyse funktioniert der Mechanismus auch in die andere Richtung: Ist die überschriebene Capture kleiner als die ursprüngliche, gibt der zu groß dimensionierte Puffer nicht initialisierte Heap-Daten zurück. Auf einem Standard-Ubuntu-24.04-Build genügt ihm zufolge eine einzige nicht authentifizierte GET-Anfrage, um die für einen Exploit nötigen Speicheradressen zu gewinnen. Die Lücke liefert den ASLR-Bypass also selbst mit.

Diese Einschätzung geht über das hinaus, was F5 im Advisory schreibt, und lässt sich derzeit nicht unabhängig prüfen. Shaw hält Exploit-Details und Proof of Concept vorerst zurück und hat eine Veröffentlichung 21 Tage nach dem Patch angekündigt, also für Anfang August. Stand 20. Juli 2026 steht CVE-2026-42533 nicht im KEV-Katalog der CISA und es ist kein öffentlicher Exploit-Code aufgetaucht. Das ist kein Grund zur Entwarnung: Bei der eng verwandten Rift-Lücke (CVE-2026-42945) im Mai lag der Exploit binnen Tagen öffentlich vor, kurz darauf liefen Angriffe.

Es ist bereits der dritte Heap Overflow in der Ausdrucksauswertung von Nginx innerhalb von rund zwei Monaten. Das gemeinsame Muster ist immer dasselbe: Ein Zwei-Pass-Verfahren, das seiner eigenen Messung vertraut.

Handlungsempfehlungen
  • Auf Nginx 1.30.4 oder 1.31.3 aktualisieren, bei NGINX Plus auf 37.0.3.1. Das ist die einzige vollständige Behebung.
  • Wer nicht sofort patchen kann, setzt die von F5 empfohlene Übergangsmaßnahme um und stellt betroffene Regex-Maps auf benannte Captures um. Achtung: Definiert eine map dieselbe benannte Gruppe wie der Regex im zugehörigen location-Block, bleibt laut Shaw ein zweiter Pfad zur selben Lücke offen. Diesen Fall erwähnt das Advisory nicht.
  • Downstream-Produkte im Blick behalten. Wer Ingress Controller, Gateway Fabric, App Protect WAF oder Instance Manager betreibt, verfolgt die Advisory-Updates von F5 und patcht nach, sobald Builds vorliegen.
  • Monitoring schärfen: Häufige Neustarts von Worker-Prozessen oder auffällige Segfault-Einträge in den Logs sind ein plausibler Hinweis auf Angriffsversuche.