18 Jahre alte NGINX-Schwachstelle erlaubt DoS und unter Umständen Codeausführung

Bei CVE-2026-42945 handelt es sich um einen Heap-Buffer-Overflow im Modul ngx_http_rewrite_module, der die NGINX-Versionen 0.6.27 bis 1.30.0 betrifft und damit seit rund 18 Jahren im Code des Projekts steckt. Auslösen lässt sich die Lücke laut DepthFirst, wenn eine NGINX-Konfiguration sowohl die Direktive „rewrite“ als auch „set“ verwendet – ein Muster, das nach Angaben der Forscher in API-Gateways und Reverse-Proxy-Aufbauten verbreitet ist.

Ursache ist eine inkonsistente Zustandsverwaltung in der internen Skript-Engine von NGINX, die Rewrites in zwei Durchläufen verarbeitet: Ein Durchlauf berechnet den zu reservierenden Speicher, der zweite kopiert die eigentlichen Daten. Ein „is_args“-Flag bleibt nach einem Rewrite mit „?“ gesetzt, sodass NGINX die Puffergröße anhand nicht-escapeter URI-Längen berechnet, später aber größere escapete Daten wie „+“ und „&“ schreibt – mit dem Overflow als Folge.

Die Forscher demonstrierten eine nicht authentifizierte Codeausführung über speziell präparierte HTTP-Anfragen, die benachbarte Speicherpool-Strukturen beschädigen, Zeiger auf Cleanup-Handler überschreiben, gefälschte Strukturen über POST-Inhalte in den Speicher einschleusen und NGINX während der Pool-Bereinigung zum Aufruf von „system()“ zwingen. Allerdings gelang die Codeausführung nur auf einem System mit deaktivierter ASLR (Address Space Layout Randomization) – einer Schutzfunktion, die standardmäßig aktiv ist, in manchen Umgebungen wie eingebetteten Systemen oder Analyse-VMs aber zugunsten der Leistung abgeschaltet wird.

DepthFirst weist darauf hin, dass die Mehrprozess-Architektur von NGINX die Ausnutzung erleichtert: Worker-Prozesse erben ein nahezu identisches Speicherlayout vom Master-Prozess. „Wenn unser Exploit fehlschlägt und einen Worker zum Absturz bringt, startet der Master-Prozess einfach einen neuen mit exakt demselben Speicherlayout“, erklären die Forscher. So lasse sich der Angriff gefahrlos so oft wiederholen, bis er gelinge; theoretisch könne man das Design nutzen, um durch byteweises Überschreiben von Zeigern die ASLR auszuhebeln.

Die drei weiteren von DepthFirst gefundenen Schwachstellen wurden als mittelschwer eingestuft. Entdeckt wurden die Fehler am 18. April 2026 und am 21. April an den Hersteller gemeldet. Laut F5-Advisory stehen Korrekturen in NGINX Open Source 1.31.0 und 1.30.1 sowie NGINX Plus R36 P4 und R32 P6 bereit. Wer nicht aktualisieren kann, soll laut F5 unbenannte PCRE-Capture-Gruppen ($1, $2 usw.) in betroffenen „rewrite“-Regeln durch benannte ersetzen, womit die zentrale Voraussetzung für die Ausnutzung entfällt.

Mehrere Sicherheitsforscher widersprechen den Aussagen zur praktischen Ausnutzbarkeit. Kevin Beaumont merkte an, dass ein Angriff eine verwundbare Konfiguration mit bestimmten Rewrite-Mustern voraussetzt, der Angreifer den betroffenen Endpunkt kennen oder finden muss und der veröffentlichte RCE-Proof-of-Concept mit deaktivierter ASLR getestet wurde; gegen gehärtete Systeme sei keine zuverlässige Codeausführung belegt.

AlmaLinux kam nach eigener Reproduktion zu einem ähnlichen Schluss: Das Abstürzenlassen von Worker-Prozessen über eine präparierte Anfrage sei trivial und zuverlässig, was DoS-Angriffe realistisch mache. Den Heap-Overflow auf Systemen mit aktiver ASLR in zuverlässige Codeausführung zu verwandeln, sei dagegen „nicht trivial“; einen generischen, verlässlichen Exploit erwarte man aus der Arbeit von DepthFirst nicht. Zugleich warnte AlmaLinux, „nicht einfach“ bedeute nicht unmöglich, und schon das DoS-Potenzial mache das Problem dringend.