CVE-2026-42945 – NGINX CVE kann RCE ermöglichen
Eine im Mai bekannt gewordene Sicherheitslücke mit dem Namen „NGINX Rift“ sorgt für Aufmerksamkeit. Die Schwachstelle betrifft das ngx_http_rewrite_module von NGINX und ist besonders bemerkenswert, da sie bereits seit dem Jahr 2008 im Quellcode vorhanden ist.
Ursprung der Schwachstelle
Der Fehler befindet sich in der Datei src/http/ngx_http_script.c und betrifft nahezu alle NGINX-Versionen bis einschließlich Version 1.30.0. Aufgrund der weiten Verbreitung von NGINX als Webserver, Reverse Proxy und Load Balancer hat die Sicherheitslücke ein erhebliches Gefährdungspotenzial.
Ein Angreifer kann durch speziell präparierte HTTP-Anfragen einen Worker-Prozess zum Absturz bringen oder unter bestimmten Bedingungen Remote Code Execution erreichen. Dies wird erreicht, indem geschriebenen Bytes kontrolliert und die Daten im Heap landen.
Genau betroffen ist der Teil von NGINX, der Rewrite Regeln bearbeitet. Diese Regeln dienen dazu, die gesamte oder einen Teil der URL, die vom Client angefordert wurde, zu ändern. Grund dafür könnte sein, den Clients mitzuteilen, dass sich der Standort der von ihnen gesuchten Ressourcen geändert hat. Neben der Steuerung des Seitenflusses in NGINX können Rewrite-Regeln auch zur Optimierung von Ladezeiten, zur SEO-Verbesserung und zur einfachen Verwaltung von Weiterleitungen beitragen.
Die NGINXs Script Engine verarbeitet die rewrite Anweisungen in zwei Durchläufen. Zunächst wird berechnet, wie viel Speicher nötig ist (Length-Pass). Im nächsten Schritt werden die Daten tatsächlich geschrieben (Copy-Pass). Dabei müssen beide Durchläufe die gleiche Länge ergeben, was sie bei der Ausnutzung der Schwachstelle nicht tun.
Ausnutzbar wird die Schwachstelle insbesondere dann, wenn Rewrite-Regeln unbenannte Captures wie $1, $2 oder $3 verwenden. Ein typisches Beispiel wäre:
Hier wird das Capture $1 in einer Ziel-URL verwendet, die ein Fragezeichen (?) enthält. Die Kombination aus unbenannten Captures und einer Rewrite-Zeichenkette mit ? aktiviert den fehlerhaften Verarbeitungspfad. Laut den Analysen tritt das Problem insbesondere dann auf, wenn auf dieselben Capture-Werte später erneut in weiteren rewrite-, if– oder set-Anweisungen zugegriffen wird. Die Konfiguration selbst ist dabei vollständig gültig und wird von nginx -t ohne Fehlermeldungen akzeptiert, weshalb die Verwundbarkeit nicht durch die übliche Konfigurationsprüfung erkannt werden kann.
Die eigentliche Diskrepanz entsteht, sobald ein Rewrite-Replacement ein ? enthält. Hierbei setzt NGINX intern das Flag is_args = 1, welches anschließend nicht mehr zurückgesetzt wird. Im Length-Pass verwendet NGINX jedoch eine neue, separate Engine. Dort hat is_args noch den Wert 0. Deshalb wird der Capture-Wert lediglich in seiner ursprünglichen Form vermessen. Hat der Wert beispielsweise eine Länge von 8 Byte, reserviert NGINX exakt 8 Byte Speicher dafür.
Danach folgt der Copy-Pass. Dieser läuft jedoch auf der Haupt-Engine, bei der is_args weiterhin auf 1 steht. Dadurch ruft NGINX die Funktion ngx_escape_uri() mit dem Flag NGX_ESCAPE_ARGS auf.
Diese Funktion maskiert bestimmte Sonderzeichen für URL-Parameter. Zeichen wie +, % oder & werden dabei von 1 Byte auf 3 Byte erweitert.
Da die Speichergröße vorher mit der ursprünglichen Größe 8 Bytes berechnet wurde, ist es dem Angreifer möglich mehr Speicher zu beschreiben, als reserviert wurde, vorausgesetzt der kontrollierte URI-Teil enthält mehrere solcher Sonderzeichen.
Enthält der URI beispielsweise drei Zeichen, die jeweils von einem auf drei Byte erweitert werden, entstehen zusätzlich sechs Byte Speicherbedarf (3 × (3 − 1)). NGINX schreibt dann insgesamt 14 Byte (8 ursprüngliche Byte plus 6 zusätzliche Byte) in einen Puffer, der lediglich 8 Byte groß ist.
Dadurch entsteht ein Heap-Buffer-Overflow. Wobei nicht zufällig Speicher überschrieben wird, denn direkt neben dem überlaufenden Puffer befindet sich häufig eine Struktur vom Typ ngx_pool_cleanup_t. Diese enthält unter anderem einen Pointer (cleanup handler). Ein Angreifer kann durch mehrere speziell vorbereitete Requests das Heap-Layout beeinflussen. Das Ziel ist dabei, den Speicher so anzuordnen, dass der Overflow genau den Funktionszeiger in einer benachbarten ngx_pool_cleanup_t-Struktur überschreibt.
Wenn NGINX später die Verarbeitung des Requests beendet, wird der Request-Pool freigegeben. Dabei durchläuft NGINX die sogenannte Cleanup-Liste und ruft alle dort registrierten Cleanup-Handler auf.
Wurde der Funktionszeiger zuvor überschrieben, führt NGINX nicht mehr die ursprünglich vorgesehene Funktion aus, sondern die vom Angreifer bestimmte Adresse. Im beschriebenen Exploit wird dadurch system() mit vom Angreifer kontrollierten Argumenten aufgerufen.
Das Ergebnis ist Remote Code Execution, also die Ausführung beliebiger Befehle auf dem betroffenen System.
Zusammenspiel zwischen CVE-2026-42945 und ASLR
Address Space Layout Randomization (ASLR) ist ein Speicherschutzmechanismus moderner Betriebssysteme, der die Speicheradressen wichtiger Bereiche eines Prozesses bei jedem Programmstart zufällig anordnet. Dazu gehören unter anderem der Heap, der Stack, geladene Bibliotheken (z. B. libc) sowie ausführbarer Programmcode.
Da die Speicherbereiche bei jedem Prozessstart zufällig gewählt werden, kennt der Angreifer die tatsächliche Adresse von system() oder anderen relevanten Codeabschnitten nicht. Selbst wenn es ihm gelingt, den Funktionszeiger zu überschreiben, würde ein Sprung zu einer falschen Adresse in der Regel lediglich zum Absturz des NGINX-Workers führen.
Die Sicherheitsforscher von depthfirst beschreiben jedoch zusätzlich eine Technik, bei der der Angreifer Speicherinformationen schrittweise gewinnt und ASLR Byte für Byte umgeht. Dadurch kann der Angriff trotz aktivierter Adressraum-Zufallisierung schließlich erfolgreich werden.
Nachstellung POC
Für die Sicherheitslücke existieren bereits öffentlich verfügbare PoCs, die einen funktionierenden Exploit demonstrieren.
POC https://github.com/F2u0a0d3/CVE-2026-42945-nginx-rift-poc
Dieser PoC wurde in einer Testumgebung nachgestellt und dabei mit dem Enginsight SIEM analysiert.
Für den Versuch wurde der im PoC enthaltene nginx-Docker-Container gestartet und das bereitgestellte Python-Skript ausgeführt. Das Skript präpariert den nginx-Heap mit einer gefälschten Datenstruktur, die einen manipulierten Funktionspointer enthält. Anschließend wird über einen speziell konstruierten URL-Pfad ein Buffer Overflow ausgelöst, der einen legitimen Funktionspointer im Heap überschreibt. Ziel ist es, dass nginx bei einem späteren internen Funktionsaufruf statt des ursprünglichen Zeigers den manipulierten Pointer verwendet und dadurch die Funktion system() mit einem vom Angreifer kontrollierten Befehl ausführt.
Erklärung POC:
Phase 1 – Vorbereitung des Heaps (Heap Spray)
Hierzu werden 20 parallele HTTP-Verbindungen aufgebaut, die jeweils einen 4000 Byte großen POST-Request an den Endpunkt /spray senden. Der Request-Body enthält eine gefälschte Datenstruktur bestehend aus der Adresse von system(), einem Datenzeiger sowie dem auszuführenden Kommando.
Durch die hohe Anzahl paralleler Verbindungen wird der Heap des nginx-Prozesses gezielt mit dieser Struktur befüllt („Heap Spray“). Die Verbindungen bleiben mittels des Headers X-Delay: 60 geöffnet, sodass die reservierten Speicherbereiche nicht freigegeben werden und die manipulierten Strukturen im Speicher verbleiben.
Phase 2 – Auslösen des Buffer Overflows
Ein einzelner GET-Request an /api/ mit einem speziell konstruierten Payload überschreibt einen Funktionspointer innerhalb einer benachbarten Connection-Struktur im Heap.
Der Payload besteht aus einem Block von A-Zeichen, einem Block aus +-Zeichen sowie einer Zieladresse. Diese Zieladresse verweist auf eine der zuvor platzierten Fake-Strukturen aus Phase 1 (HEAP_BASE + Offset). Durch den Overflow wird der ursprüngliche Funktionspointer auf diese Adresse umgebogen.
Phase 3 – Ausführung und Validierung
Nach dem Überschreiben des Funktionspointers überprüft das Skript, ob der betroffene nginx-Worker weiterhin reagiert oder abgestürzt ist.
Ein Absturz deutet darauf hin, dass der Funktionspointer erfolgreich überschrieben wurde. Ob tatsächlich ein Aufruf von system() erfolgt, hängt davon ab, ob die verwendete Zieladresse exakt auf eine gültige Fake-Struktur zeigt. Falls dies nicht der Fall ist, wird der nächste Offset aus der Liste PREREAD_HEAP_OFFSETS verwendet und der Vorgang erneut gestartet.
Analyse der Logdaten:
In den Logs sind folgende Ereignisse erkennbar:
- Rewrite-Match mit dem Payload
Der Payload besteht aus drei Komponenten:
- 349 × „A“
Dient als Padding und positioniert den Schreibzeiger des Overflows an die gewünschte Stelle im Heap. - 969 × „+“
Dieser Teil triggert die eigentliche Schwachstelle. nginx reserviert den Speicher anhand der ursprünglichen Länge des Puffers, schreibt beim Dekodieren von%2Bjedoch mehr Daten als vorgesehen. Dadurch entsteht der Buffer Overflow. - „4kUUU“ (Adressbytes)
Enthält die Zieladresse als rohe, Latin-1-kodierte Bytes. Dabei handelt es sich um die sechs niederwertigen Bytes vonHEAP_BASE + Offset, auf die der überschriebenen Funktionspointer später zeigen soll. - Rewrite auf
/internal?migrated=true
Der fehlerhafte Codepfad wird durchlaufen und der Overflow ausgelöst.
- Absturz des nginx-Workers
Worker 9 beendet sich aufgrund eines Segmentation Faults (Signal 11) und erzeugt einen Core Dump.
- Automatischer Neustart des Workers
Der nginx-Masterprozess startet den abgestürzten Worker neu.
Darstellung in Enginsight
In Enginsight besteht die Möglichkeit, sowohl native nginx-Logs als auch die Logdaten von Docker-Containern direkt an das SIEM zu übertragen. Da der PoC innerhalb eines Docker-Containers ausgeführt wurde, basiert die Analyse auf den erfassten Container-Logs. Die enthaltenen nginx-Logs werden dabei automatisch geparst und aufbereitet, sodass die für den Exploit relevanten Ereignisse, insbesondere der Rewrite-Match sowie der anschließende Absturz des nginx-Workers, zentral erfasst und im SIEM nachvollzogen werden können.
Alarmierung in Enginsight:
Die beiden identifizierten SIEM-Ereignisse können zur Erstellung einer Korrelationsregel genutzt werden, die einen Alarm auslöst, wenn unmittelbar nach einem Rewrite-Vorgang ein Absturz eines nginx-Workers festgestellt wird.
Eine solche Alarmierung ist sinnvoll, da die Kombination aus Rewrite-Aktivität und anschließendem Worker-Absturz auf einen möglichen Ausnutzungsversuch der beschriebenen Schwachstelle hindeuten kann. Während einzelne Rewrite-Operationen oder Worker-Neustarts im regulären Betrieb auftreten können, stellt das zeitliche Zusammentreffen beider Ereignisse ein auffälliges Muster dar, das auf die Ausführung eines Exploits oder einen fehlgeschlagenen Angriffsversuch schließen lässt. Anbei wird gezeigt, wie die entsprechenden SIEM Streams auszusehen haben:
Regel Nummer 1: Rewrite Match
Achtung: Für diese Log muss das Log-Level des Error Logs auf notice stehen sowie das rewrite-log aktiviert sein. Das ist über die nginx.conf möglich:
http– oder server block
Regel Nummer 2: Worker Crash:
Die zwei Streams können genutzt werden, um einen Workflow, wie folgt, zu erstellen.
Bei einer erneuten Ausführung des PoC ist erkennbar, dass der Workflow erfolgreich ausgelöst wurde. Nach dem Öffnen des entsprechenden Ereignisses lässt sich nachvollziehen, welche Aktivität die Alarmierung verursacht hat und welche Ereignisse zur Auslösung des Workflows geführt haben.
Ursachenanalyse
Der PoC demonstriert grundsätzlich die erfolgreiche Ausnutzung der Schwachstelle. Allerdings konnte im Test kein erfolgreicher Aufruf von system() beobachtet werden.
Ursache hierfür ist die aktivierte Address Space Layout Randomization (ASLR). Die im PoC hinterlegten Speicheradressen entsprechen nicht der tatsächlichen Laufzeitumgebung des Containers.
Im PoC wird beispielsweise folgende Heap-Basisadresse angenommen:
Im Testcontainer befand sich der Heap jedoch bei:
Dadurch verweisen sämtliche im PoC hinterlegten PREREAD_HEAP_OFFSETS auf falsche Zieladressen. Der überschriebene Funktionspointer zeigt folglich nicht auf die präparierte Datenstruktur, sondern auf ungültige Speicherbereiche. Statt eines Aufrufs von system() resultiert dies in einem Absturz des nginx-Workers.
Die verwendeten Offsets beschreiben lediglich den Abstand zwischen Heap-Basis und Zielstruktur. Dieser Abstand bleibt zwar unverändert, aufgrund der verschobenen Heap-Basis müssten die Offsets jedoch entsprechend angepasst werden, um wieder auf dieselbe absolute Speicheradresse zu zeigen.
Fazit
Der nachgestellte PoC zeigt trotz des fehlgeschlagenen Aufrufs von system(), dass die zugrunde liegende Schwachstelle erfolgreich ausgenutzt werden kann. Das Überschreiben eines Funktionspointers sowie der daraus resultierende Absturz des nginx-Workers belegen die technische Funktionsfähigkeit des Exploits.
In Umgebungen ohne ASLR oder bei korrekter Anpassung der verwendeten Adressen wäre grundsätzlich die Ausführung beliebiger Befehle denkbar. Dies könnte im Erfolgsfall zur Erlangung einer Remote Shell und damit zu einer vollständigen Kompromittierung des betroffenen Systems führen.
