Kritische NGINX-Lücke seit 18 Jahren im Code: Angreifer scannen bereits aktiv
NGINX ist eine der meistgenutzten Webserver-Lösungen weltweit. Die Software steckt in Reverse-Proxys, Load Balancern, API-Gateways und Kubernetes-Ingress-Controllern. Eine Schwachstelle, die seit 2008 im Code schlummerte, ist jetzt bekannt und wird aktiv ausgenutzt. Wer NGINX betreibt, sollte sofort handeln.
Was ist passiert?
Sicherheitsforscher des Unternehmens Depthfirst haben im Modul ngx_http_rewrite_module einen Heap-Buffer-Overflow entdeckt und verantwortungsbewusst an F5 gemeldet. F5 hat am 13. Mai 2026 gepatchte Versionen veröffentlicht. Noch am gleichen Tag publizierten die Forscher technische Details und einen Proof-of-Concept-Exploit.
Drei Tage später, am 16. Mai 2026, begannen VulnChecks Honeypot-Systeme, aktive Ausnutzungsversuche zu protokollieren. Seitdem scannen Angreifer automatisiert nach ungepatchten NGINX-Instanzen.
Die Schwachstelle trägt die Kennung CVE-2026-42945 und wird von der National Vulnerability Database mit einem CVSS-4.0-Score von 9.2 als kritisch eingestuft.
Wie funktioniert der Angriff?
Das Problem liegt in der Art, wie das Rewrite-Modul bestimmte Konfigurationen verarbeitet. Konkret entsteht ein Größenkonflikt zwischen zwei Durchläufen über den Ersetzungsstring einer Rewrite-Direktive. Wenn eine solche Direktive eine unbenannte PCRE-Capture-Gruppe ($1, $2) nutzt und der Ersetzungstext ein Fragezeichen enthält, und danach eine weitere rewrite-, if- oder set-Direktive folgt, kann ein Angreifer den Worker-Prozess mit einer einzigen präparierten HTTP-Anfrage zum Absturz bringen. Keine Authentifizierung erforderlich.
Beim Absturz startet NGINX den Worker automatisch neu. Das führt zu einer Absturz-Neustart-Schleife, solange die Anfragen andauern. Der Dienst ist damit effektiv nicht erreichbar.
Gefährlicher wird es, wenn auf dem System der Speicherschutzmechanismus ASLR (Address Space Layout Randomization) deaktiviert oder umgehbar ist. In diesem Fall ist Remote Code Execution möglich: Ein Angreifer kann fremden Code direkt auf dem Server ausführen. Ein öffentlich verfügbarer Proof-of-Concept, der ASLR umgeht, ist seit dem 19. Mai 2026 bekannt.
Wer ist betroffen?
Betroffen sind alle NGINX Open Source-Versionen von 0.6.27 bis 1.30.0 sowie NGINX Plus R32 bis R36. Der Fehler steckt seit etwa 18 Jahren im Code. Nicht direkt betroffen sind F5-Produkte wie BIG-IP, BIG-IQ oder F5 Distributed Cloud.
Besonders zu beachten: Die Schwachstelle greift nur, wenn die aktive NGINX-Konfiguration Rewrite-Regeln mit unbenannten Captures enthält. Wer keine solchen Direktiven nutzt, ist vor dem Remote-Code-Execution-Szenario geschützt, bleibt aber bei einem Denial-of-Service in manchen Konfigurationen exponiert. Eine Prüfung der eigenen Konfiguration ist dennoch Pflicht.
- NGINX Open Source auf Version 1.30.1 (stable) oder 1.31.0 (mainline) aktualisieren.
- NGINX Plus auf R32 P6, R35 P2 oder R36 P4 aktualisieren.
- Container-Images und Kubernetes-Ingress-Controller gesondert prüfen: In eingebetteten NGINX-Instanzen muss der Patch separat eingespielt werden.
- Web-Server-Logs auf ungewöhnliche HTTP-Request-Muster prüfen, die auf laufende Scanversuche hindeuten.