Eine 18 Jahre alte Schwachstelle im Open-Source-Webserver **NGINX**, die mit einem autonomen Scansystem entdeckt wurde, kann für Denial of Service und unter bestimmten Bedingungen für Remote Code Execution ausgenutzt werden. Die Schwachstelle wird als **CVE-2026-42945** verfolgt und erhielt eine kritische Schweregradbewertung von 9,2, basierend auf der neuesten Version des Common Vulnerability Scoring System (**CVSS**). Drei weitere Speicherbeschädigungs-Sicherheitsprobleme wurden in derselben sechsstündigen Code-Scanning-Sitzung von Forschern des KI-nativen Sicherheitsunternehmens **DepthFirst AI** entdeckt. **NGINX** ist eine weit verbreitete Webserver- und Reverse-Proxy-Plattform, die ein Drittel der Top-Websites antreibt. Sie kann den Datenverkehr effizient verteilen, indem sie eingehenden Netzwerkverkehr auf mehrere Backend-Server verteilt, und Ladezeiten reduzieren, indem sie Inhalte zwischenspeichert. Der Webserver, der von der amerikanischen Tech-Firma **F5** besessen und gewartet wird, wird von Cloud-Anbietern, SaaS-Unternehmen, Banken, Medienplattformen, E-Commerce-Websites und in Kubernetes-Clustern verwendet. **CVE-2026-42945** ist ein Heap-Buffer-Overflow im `ngx_http_rewrite_module`, der **NGINX**-Versionen 0.6.27 bis 1.30.0 betrifft und seit etwa 18 Jahren im Code des Projekts vorhanden ist. Laut **DepthFirst** kann die Schwachstelle ausgelöst werden, wenn **NGINX**-Konfigurationen sowohl die Direktiven 'rewrite' als auch 'set' verwenden, ein Muster, das laut den Forschern in API-Gateways und Reverse-Proxy-Setups üblich ist. Die Lücke ergibt sich aus der inkonsistenten Zustandsbehandlung in der internen Skript-Engine von **NGINX**, die Rewrites in zwei Durchgängen verarbeitet: einen zur Berechnung der zu allozierenden Speichermenge und einen zum Kopieren der eigentlichen Daten. Ein 'is_args'-Flag bleibt nach einem Rewrite, der '?' enthält, gesetzt, was dazu führt, dass **NGINX** die Puffergröße anhand der unescaped URI-Längen berechnet, aber später größere escaped Daten wie '+' und '&' schreibt, was zu einem Heap-Buffer-Overflow führt. Die Forscher demonstrierten eine unauthentifizierte Codeausführung über speziell gestaltete HTTP-Anfragen, die benachbarte Speicherpool-Strukturen von **NGINX** beschädigen, Cleanup-Handler-Zeiger überschreiben, über POST-Anfragekörper gefälschte Strukturen in den Speicher sprühen und **NGINX** zwingen, `system()` während der Poolbereinigung auszuführen. Die Remote Code Execution wurde jedoch auf einem System erreicht, auf dem die Adressraum-Layout-Randomisierung (**ASLR**)-Schutz vor speicherbasierten Angriffen deaktiviert war. Diese Abwehr ist standardmäßig aktiv, kann aber zur Leistungssteigerung in einigen Umgebungen deaktiviert werden, wie z. B. in eingebetteten Systemen und virtuellen Maschinen, die zur Analyse verwendet werden. **DepthFirst** stellt fest, dass die Multi-Prozess-Architektur von **NGINX** die Ausnutzung erleichtert, da Worker-Prozesse nahezu identische Speicherlayouts vom Master-Prozess erben, was eine zuverlässige Heap-Manipulation und wiederholte Versuche ermöglicht, falls ein Worker abstürzt. "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. "Dies ermöglicht es uns, sicher mehrere Versuche zu unternehmen, bis wir erfolgreich sind, ohne uns darum kümmern zu müssen, dass der Worker abstürzt und das Speicherlayout ändert." "Theoretisch könnten wir dieses Design nutzen, um **ASLR** (Address Space Layout Randomization) durch schrittweises Überschreiben von Zeigern Byte für Byte zu leaken." Die anderen drei von **DepthFirst** aufgedeckten Lücken erhielten eine mittlere Schweregradbewertung: * **CVE-2026-42946** — übermäßige Speicherzuweisung in SCGI/UWSGI-Modulen, die Worker über ~1 TB Allokationen zum Absturz bringen kann (hoher Schweregrad) * **CVE-2026-40701** — Use-after-free bei der asynchronen OCSP-DNS-Auflösungsbehandlung (mittlerer Schweregrad) * **CVE-2026-42934** — Off-by-one UTF-8-Parsing-Fehler, der Out-of-Bounds-Lesevorgänge verursacht (mittlerer Schweregrad) ### Auswirkungen und Behebungen Die Schwachstellen wurden am 18. April 2026 entdeckt und am 21. April dem Anbieter gemeldet. Laut dem gestern veröffentlichten Sicherheitsratgeber von **F5** betreffen die Lücken die folgenden **NGINX**-Builds: * **NGINX** Open Source Versionen 0.6.27 bis 1.30.0 * **NGINX** Plus R32 bis R36 * **NGINX** Instance Manager 2.16.0 bis 2.21.1 * **F5** WAF für **NGINX** 5.9.0 bis 5.12.1 * **NGINX** App Protect WAF 4.9.0 bis 4.16.0 und 5.1.0 bis 5.8.0 * **F5** DoS für **NGINX** 4.8.0 * **NGINX** App Protect DoS 4.3.0 bis 4.7.0 * **NGINX** Gateway Fabric 1.3.0 bis 1.6.2 und 2.0.0 bis 2.5.1 * **NGINX** Ingress Controller 3.5.0 bis 3.7.2, 4.0.0 bis 4.0.1 und 5.0.0 bis 5.4.1 Korrekturen wurden in **NGINX** Open Source 1.31.0 und 1.30.1, **NGINX** Plus R36 P4 und **NGINX** Plus R32 P6 verfügbar gemacht. Für diejenigen, die kein Upgrade durchführen können, empfiehlt **F5**, unbenannte PCRE-Capture-Gruppen ($1, $2 usw.) in anfälligen 'rewrite'-Regeln durch benannte Captures zu ersetzen, was die Hauptvoraussetzung für die Ausnutzung beseitigt. ### Ausnutzbarkeit in der Praxis Einige Sicherheitsexperten haben die Behauptungen zur realen Ausnutzbarkeit von **CVE-2026-42945** zurückgewiesen und argumentiert, dass der Proof-of-Concept von **DepthFirst** auf sehr spezifische Bedingungen angewiesen ist, die in Standardinstallationen nicht häufig vorkommen. Forscher Kevin Beaumont merkte an, dass die Ausnutzung eine anfällige **NGINX**-Konfiguration mit bestimmten Rewrite-Mustern erfordert, der Angreifer den betroffenen Endpunkt kennen oder entdecken muss und der veröffentlichte RCE PoC mit deaktiviertem **ASLR** getestet wurde. Beaumont betonte, dass der Exploit der Forscher gegen ein absichtlich anfälliges Setup erstellt wurde und keine zuverlässige Codeausführung gegen gehärtete reale Systeme demonstriert.  **AlmaLinux** äußerte eine ähnliche Einschätzung in seinem Advisory, nachdem die Lücke unabhängig reproduziert wurde. Die Maintainer der Linux-Distribution bestätigten, dass das Abstürzen von **NGINX**-Worker-Prozessen über eine präparierte Anfrage trivial und zuverlässig ist, was Denial-of-Service-Angriffe realistisch macht. Sie stellten jedoch fest, dass die Umwandlung des Heap-Overflows in eine zuverlässige Remote Code Execution auf Systemen mit aktiviertem **ASLR** "nicht trivial" ist und sie keinen generischen, zuverlässigen Exploit erwarten, der aus der Arbeit von **Depthfirst** hervorgeht. Gleichzeitig warnte **AlmaLinux**, dass "nicht einfach" nicht "unmöglich" bedeutet und das DoS-Potenzial allein ausreicht, um das Problem als dringend einzustufen. ## Die Validierungslücke: Automatisierte Pentests beantworten eine Frage. Sie brauchen sechs. Automatisierte Pentesting-Tools liefern echten Mehrwert, aber sie wurden entwickelt, um eine Frage zu beantworten: Kann ein Angreifer sich im Netzwerk bewegen? Sie wurden nicht entwickelt, um zu testen, ob Ihre Kontrollen Bedrohungen blockieren, Ihre Erkennungsregeln auslösen oder Ihre Cloud-Konfigurationen standhalten. Diese Anleitung behandelt die 6 Oberflächen, die Sie tatsächlich validieren müssen. [Jetzt herunterladen](https://hubs.li/Q048zztN0)