Ein einziger Aufruf reicht. F5 hat eine kritische Sicherheitslücke im weltweit meistgenutzten Webserver geschlossen — und die betrifft potenziell Millionen Server. Wenn dein Homelab, dein Reverse-Proxy oder deine WordPress-Seite hinter NGINX läuft, solltest du HEUTE handeln.
NEUE LÜCKE: So knackt eine Anfrage den Worker
Die Schwachstelle trägt die Kennung CVE-2026-42533 und steckt in NGINX‘ Script-Engine — dem Code, der zur Laufzeit Zeichenketten aus Direktiven zusammenbaut. F5 hat den Fehler am 15. Juli in NGINX 1.30.4 (stable) und 1.31.3 (mainline) sowie in NGINX Plus 37.0.3.1 behoben.
Der Auslöser ist ein sogenannter Heap-Buffer-Overflow. NGINX misst in einem ersten Durchgang, wie viele Bytes das Ergebnis braucht, und reserviert dafür Speicher. Im zweiten Durchgang schreibt es die Bytes hinein. Das Problem: Beide Durchgänge greifen auf denselben Zwischenspeicher zu — und die Auswertung einer regex-basierten map dazwischen überschreibt ihn. Der Messdurchgang plant für die eine Größe, der Schreibdurchgang füllt aus einer anderen, größeren. Der Puffer ist zu klein, Länge und Inhalt des Überlaufs kommen direkt aus der Anfrage.
GEFAHR: Nicht nur Absturz
Ein Treffer lässt den Worker-Prozess abstürzen oder neu starten — das ist ein klassischer Denial-of-Service. F5 warnt aber: Wo die Speicher-Schutztechnik ASLR deaktiviert ist oder umgangen werden kann, ist auch Codeausführung denkbar. F5 bewertet die Lücke mit CVSS 9,2 (v4) beziehungsweise 8,1 (v3.1) und stuft die Angriffskomplexität als hoch ein.
Ein Sicherheitsforscher geht weiter: Stan Shaw, der als cyberstan publiziert, hält die reine DoS-Einordnung für gefährlich verharmlosend. Auf einem Standard-Ubuntu-24.04-Build könne bereits eine einzige unauthentifizierte GET-Anfrage die Speicheradressen preisgeben, die ein Angreifer für einen Exploit braucht. Die Details und einen fertigen Proof-of-Concept hält er vorerst zurück — angekündigt hat er die Veröffentlichung für 21 Tage nach dem Patch.
BETRIFFT DICH DAS? Der Blick in die Config
Verwundbar sind laut F5 alle NGINX-Versionen von 0.9.6 bis 1.31.2 — ein Bereich, der bis 2011 zurückreicht, als map die Regex-Unterstützung bekam. Aber: Nicht jeder Server ist automatisch angreifbar. Die Gefahr entsteht nur bei einer bestimmten Konfiguration — einer regex-basierten map, deren Ausgabevariable in einem String-Ausdruck neben einer nummerierten Erfassung ($1, $2) aus einem früheren Regex auftaucht.
EXTRA-TIPP: Als Übergangslösung empfiehlt F5, betroffene regex-Maps auf benannte Captures umzustellen. Shaw weist aber auf eine schmale Restlücke hin, die dabei offen bleibt — ein vollständiger Schutz ergibt sich nur durch das Update auf 1.30.4 beziehungsweise 1.31.3.
Bereits ausgenutzt?
Stand 20. Juli stand CVE-2026-42533 nicht auf der Known-Exploited-Liste der US-Behörde CISA, und öffentlicher Exploit-Code war noch nicht aufgetaucht. Zur Beruhigung sollte das aber niemanden verleiten: Es ist bereits der dritte Heap-Overflow in NGINX‘ Ausdrucks-Engine binnen rund zwei Monaten — und beim Mai-Fall Rift (CVE-2026-42945) ging der Exploit innerhalb von Tagen live, gefolgt von aktiver Ausnutzung.
FAZIT: Warte nicht auf den PoC. Prüfe deine NGINX-Version und update, bevor der Angriffscode kursiert.
Häufige Fragen
Welche NGINX-Versionen sind betroffen?
map, deren Variable zusammen mit einer nummerierten Regex-Erfassung in einem String-Ausdruck steht. Ohne diese Konfiguration ist der konkrete Angriff nicht auslösbar.Wie merke ich, ob mein Server verwundbar ist?
map-Blöcken, deren Ausgabevariable neben einem $1/$2-Capture in einer Zeichenkette verwendet wird. Der Melder cyberstan hat einen Config-Scanner veröffentlicht, der Includes verfolgt und nur die ausnutzbare Reihenfolge markiert — er greift nichts an, sondern prüft nur.