Die Schwachstelle ist ein Heap-Buffer-Overflow im Modul ngx_http_rewrite_module und wird durch eine inkonsistente Zustandsverwaltung in NGINXs internem Script-Engine verursacht. Das Problem entsteht, wenn Konfigurationen sowohl die Direktiven ‘rewrite’ als auch ‘set’ nutzen – ein Muster, das besonders bei API-Gateways und Reverse-Proxy-Setups häufig vorkommt.
Die technische Ursache liegt in einem fehlerhaften Flag namens ‘is_args’, das nach einem Rewrite mit ‘?’ gesetzt bleibt. Dies führt dazu, dass NGINX die Puffergröße basierend auf unescaped-URI-Längen berechnet, später aber größere escaped-Daten schreibt – etwa ‘+’ und ‘&’-Zeichen. Die Folge ist ein Heap-Buffer-Overflow, der die Speicherstrukturen von NGINX beschädigt.
Die Sicherheitsforscher von DepthFirst AI demonstrierten, dass unauthentifizierte Code-Execution über speziell präparierte HTTP-Requests möglich ist. Die Exploit-Chain überschreibt Cleanup-Handler-Pointer, injiziert gefälschte Strukturen via POST-Request-Bodies und zwingt NGINX zur Codeausführung während der Pool-Bereinigung. Allerdings wurde die RCE auf Systemen ohne ASLR-Schutz erreicht – ein Standard-Sicherheitsmechanismus, der auf modernen Systemen aktiviert ist.
Der praktische Exploitierbarkeit wird daher von der Sicherheitscommunity skeptisch beurteilt. Forscher Kevin Beaumont und die Linux-Distribution AlmaLinux argumentieren, dass die PoC unter sehr spezifischen Bedingungen funktioniert, die in Standard-Deployments selten vorkommen. Sie bestätigten zwar, dass DoS-Attacken trivial und zuverlässig sind, stufen aber echte RCE auf gehärteten Produktionssystemen als nicht praktizierbar ein.
NGINXs Multi-Prozess-Architektur begünstigt allerdings die Exploitation: Worker-Prozesse erben nahezu identische Speicherlayouts vom Master-Prozess, was zuverlässige Heap-Manipulation und wiederholte Exploitierungsversuche ermöglicht. Jeder abgestürzte Worker wird durch einen neuen mit gleichem Layout ersetzt.
F5 hat Patches in Version 1.31.0, 1.30.1 und den NGINX-Plus-Varianten R36 P4 und R32 P6 veröffentlicht. Als Workaround empfiehlt der Hersteller, unbenannte PCRE-Capture-Groups ($1, $2) durch benannte Captures zu ersetzen, was die Exploit-Voraussetzung eliminiert. AlmaLinux warnt jedoch: Auch wenn echte RCE schwierig ist, macht das Denial-of-Service-Potenzial die Lücke zu einem dringenden Sicherheitsfall.