Kritische Schwachstelle im NGINX-Rewrite-Modul NGINX-Lücke von 2008 gefährdet Webserver weltweit

Von Thomas Joos 2 min Lesedauer

Eine seit 2008 vorhandene Speicherschwachstelle im Rewrite-Modul von NGINX gefährdet Webserver und Reverse-Proxys in produktiven Um­ge­bung­en. Ein einziger manipulierter HTTP-Request reicht für den Absturz des Worker-Prozesses, unter bestimmten Bedingungen sogar für die Ausführung von Code.

Eine seit 2008 unentdeckte Schwachstelle im NGINX-Rewrite-Modul ermöglicht unauthentifizierte Codeausführung per HTTP-Request. Administratoren sollten umgehend auf eine gepatchte Version aktualisieren.(Bild:  Dall-E / KI-generiert)
Eine seit 2008 unentdeckte Schwachstelle im NGINX-Rewrite-Modul ermöglicht unauthentifizierte Codeausführung per HTTP-Request. Administratoren sollten umgehend auf eine gepatchte Version aktualisieren.
(Bild: Dall-E / KI-generiert)

F5 bewertet CVE-2026-42945 nach CVSS 4.0 mit 9.2 (kritisch) und nach CVSS 3.1 mit 8.1 (hoch). Das Sicherheitsunternehmen depthfirst gab dem Fehler den Namen NGINX Rift. Aufgespürt hat ihn ein autonomes KI-gestütztes Analysesystem, das den Quellcode im April 2026 in rund sechs Stunden durchsucht hat. Die verantwortliche Offenlegung datiert auf den 21.04.2026, F5 bestätigt am 24.04.2026 und veröffentlicht das Advisory am 13.05.2026.

Das Rewrite-Modul verarbeitet Captures fehlerhaft

Der Defekt sitzt im ngx_http_rewrite_module, dem Bestandteil für die Umschreibung von URIs. Verwundbar ist eine rewrite-Direktive mit einer unbenannten PCRE-Capture (Perl-Compatible Regular Expression) der Form $1 oder $2, deren Ersatzstring ein Fragezeichen enthält und auf die eine weitere rewrite-, if- oder set-Direktive folgt. In dieser Konstellation berechnet die Skript-Engine die Puffergröße im ersten Durchgang anders, als sie im zweiten schreibt. Ein internes is_args-Flag aus der Längenberechnung reicht in die Kopierphase hinein, sodass ngx_escape_uri über die reservierte Allokation hinausschreibt. Zeichen darunter +, % und & dehnen sich beim erneuten Escaping aus, der Schreibvorgang verlässt das Pufferende. Der Konfigurationstest „nginx -t“ meldet das Muster nicht, da die Konfiguration syntaktisch gültig bleibt.

Ein unauthentifizierter Angreifer löst den Heap-Überlauf mit einem einzigen präparierten HTTP-Request aus. Die unmittelbare Folge ist ein Absturz des Worker-Prozesses und ein Neustart in einer Schleife, also eine Denial-of-Service-Situation. Bei deaktiviertem oder umgangenem ASLR (Address Space Layout Randomization) reicht die Manipulation bis zur Ausführung von Code im Worker-Prozess.

Betroffene Versionen und verfügbare Patches

Der Fehler steckt seit Version 0.6.27 aus dem Jahr 2008 im Code und bleibt rund 18 Jahre unentdeckt. NGINX Open Source ab 0.6.27 bis vor 1.30.1 gilt als verwundbar, ab 1.31.0 nicht mehr. Das Projekt liefert die Korrektur im Stable-Branch mit 1.30.1 und im Mainline-Branch mit 1.31.0. Bei NGINX Plus sind die Versionen R32 bis vor R32 P6 sowie R33, R34, R35 und R36 bis vor R36 P4 verwundbar. R37 ist nicht betroffen. Versionen jenseits des technischen Supports hat F5 nicht bewertet.

Sofortmaßnahmen ohne Patch

Lässt sich ein Update nicht sofort einspielen, beseitigen Administratoren die Auslösebedingung direkt in der Konfiguration. Der Austausch unbenannter Captures gegen benannte Captures in jeder betroffenen rewrite-Direktive nimmt dem Angriff die Grundlage. Internetzugängliche Reverse-Proxys, API-Gateways und Ingress-Controller in Kubernetes verdienen Vorrang, da jeder unauthentifizierte Einstiegspunkt unmittelbar gefährdet ist. Das Team von depthfirst hat einen Proof of Concept veröffentlicht, der die Überlauf-Technik mit einer ASLR-Bypass-Kette über einen lokalen Datei-Lesezugriff verbindet und so unauthentifizierte Codeausführung demonstriert. Parallel meldet F5 mit CVE-2026-42946 (CVSS 8.3) eine zweite Lücke in den Modulen für SCGI und uWSGI, die eine überhöhte Speicheranforderung auslöst.

Fazit

Die Lücke belegt die lange Verweildauer eines Speicherfehlers in stark genutzter Infrastruktur. Das verwundbare Muster aus rewrite-Direktive mit Fragezeichen, unbenannter Capture und nachfolgender set-Direktive zählt zu den verbreiteten Konfigurationen vor Anwendungs-Backends. Ein Update auf eine korrigierte Version oder die Umstellung auf benannte Captures schließt das Risiko.

(ID:50859772)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung