NGINX Rift – neuer NGINX-Exploit

• NGINX Rift ist ein Remote-Code-Execution-PoC für CVE-2026-42945, einen kritischen Heap-Buffer-Overflow in NGINX ngx_http_rewrite_module
• Die Schwachstelle ermöglicht unauthentifizierte Remote Code Execution auf Servern, die die Direktiven rewrite und set verwenden
• Das Problem ist ein 2008 eingeführter Bug, der dadurch entsteht, dass der Längenberechnungs-Pass und der Kopier-Pass der NGINX-Skript-Engine das Flag is_args unterschiedlich behandeln
• Wenn der rewrite-Ersetzungsstring ein ? enthält, wird im Haupt-Engine is_args gesetzt, die Längenberechnung läuft jedoch in einer neu mit 0 initialisierten Sub-Engine und gibt daher nur die Länge der ursprünglichen Captures zurück
• In der Kopierphase werden ngx_escape_uri und NGX_ESCAPE_ARGS mit is_args = 1 aufgerufen, wodurch jedes escapebare Byte auf 3 Byte erweitert wird und der zu klein allokierte Heap-Puffer mit vom Angreifer kontrollierten URI-Daten überläuft
• Der Exploit verwendet Heap Feng Shui über mehrere Requests hinweg, um den cleanup-Pointer eines benachbarten ngx_pool_t zu korrumpieren; da in URI-Bytes keine Null-Bytes eingebracht werden können, erfolgt das Sprayen über den POST-Body
• Der korrumpierte Pointer wird auf ein gefälschtes ngx_pool_cleanup_s umgeleitet und so vorbereitet, dass bei der Zerstörung des Pools system() aufgerufen wird
• Neben CVE-2026-42945 wurden auch drei weitere Memory-Corruption-Probleme – CVE-2026-42946, CVE-2026-40701 und CVE-2026-42934 – vom Sicherheitsanalyse-System von depthfirst nach einmaligem Onboarding des NGINX-Quellcodes autonom entdeckt
• Betroffen sind NGINX Open Source 0.6.27–1.30.0 und NGINX Plus R32–R36; als behobene Versionen werden Open Source 1.31.0/1.30.1 sowie Plus R36 P4/R35 P2/R32 P6 genannt
• Die vollständige Herstellerwarnung steht unter https://my.f5.com/manage/s/article/K000160932, technische Details im technical write-up
• Der PoC wurde unter Ubuntu 24.04.3 LTS getestet und beschreibt den Ablauf zum Starten eines verwundbaren NGINX-Containers und zum Öffnen einer Shell in der Reihenfolge ./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell

[GN⁺]

Hacker-News-Kommentare

• Als Sicherheitsverantwortlicher bin ich es leid, wie viele Reaktionen ausdrücklich oder implizit davon ausgehen, dass dieses Problem viel weniger beängstigend sei, nur weil der veröffentlichte Exploit ASLR nicht umgeht
  Im Originaltext wird behauptet, dass es eine Möglichkeit gibt, ASLR bei diesem Angriff zuverlässig zu umgehen, und ich halte das auch ohne Belege für eine plausible Standardannahme
  ASLR ist nur eine Defense-in-Depth-Technik, die Exploits erschweren soll, und in den meisten Fällen wird mit genug Zeit und Können irgendwann ein ASLR-Bypass hinzugefügt
  Wegen LLM-Agenten sinkt auch die Hürde bei Zeit und Können alle paar Wochen, daher ist es nur eine Frage der Zeit, bis ein vollständig weaponisierter Exploit auftaucht, ob öffentlich oder privat
  Die Aussage „Wenn ASLR aktiviert ist, ist es nicht gefährlich“ ist eindeutig falsch und für Menschen, die so etwas glauben, sehr schädlich
  Der falsche Glaube, dass man sich um Sicherheitslücken nicht kümmern müsse, weil Mitigations Exploits erschweren können, hat in der Vergangenheit bereits großen Schaden angerichtet
  Moderne Mitigations sind zwar erfreulich, aber man sollte trotzdem so schnell wie möglich patchen, und als Vendor sollte man einen Vulnerability-Report nicht als ungültig abtun, nur weil der Forscher keinen ASLR-Bypass gezeigt hat, sondern die eigentliche Ursache beheben

  • Remote erreichbare Schwachstellen sollte man nicht auf die leichte Schulter nehmen
    Im Moment wirken die Voraussetzungen allerdings etwas speziell
    Ich habe nginx zehn Jahre lang in verschiedenen Konfigurationen verwendet, aber rewrite und set nie gemeinsam eingesetzt
  • Man kann ziemlich sicher sagen, dass die Leute, die behaupten „AI wird Cyber lösen“, und die Leute, die sagen „Mit aktiviertem ASLR ist alles okay“, deckungsgleich sind
    Und sie sagen natürlich auch immer „cyber“
  • Ich stimme dieser Sichtweise nicht zu, oder würde es zumindest anders formulieren
    ASLR ist wie ein zusätzliches Passwort, das getroffen werden muss, hat eine gewisse Entropie und ist normalerweise stabil
    Wenn die Schwachstelle keinen Information-Disclosure-Teil hat, dann mitigiert ASLR sie entweder vollständig, oder es wird eine zweite Schwachstelle benötigt
    Das ist eine andere Diskussion
    ASLR kann einzelne Schwachstellen vollständig mitigieren, auch wenn es keine ganze Exploit-Chain verhindern kann
    Um schnelles Patchen zu begründen, wäre es meiner Meinung nach trotzdem besser, auf die Möglichkeit einer zweiten Schwachstelle zu verweisen, die ein Information Leak erzeugt
    Exploit-Chains sind bei allen Arten von Schwachstellen riskant
  • Es ist schwer, die Verbreitung von Fehlinformationen im Internet zu verhindern, und die meisten wissen nicht einmal, dass sie falsch liegen
    Wirklich schädlich ist es, zufälligen Internetkommentaren mit voller Überzeugung zu glauben
    Wenn man die Fähigkeit entwickelt, so etwas zu durchschauen, hilft das nicht nur in der Sicherheit, sondern auch anderswo
  • Wenn ich einen Bericht über Remote Code Execution in öffentlich zugänglicher Software lese, upgrade ich normalerweise innerhalb weniger Minuten
    Genau deshalb lese ich solche Berichte, und man sollte sie ernst nehmen
    Sonst wird die Maschine bald kompromittiert
    In letzter Zeit wirkt es so, als würden viele veröffentlichte Remote-Code-Execution-Exploits ohne Vorwarnung erscheinen, und ich wünschte, man würde einem zumindest ein paar Minuten zum Upgrade geben
    Das erinnert an die Zeit ohne Sicherungsmechanismen bei Veröffentlichungen Ende der 1980er und Anfang der 1990er, als remote ausnutzbare sendmail-Bugs nur so herauskamen
    Wenn man solche Berichte nicht liest oder zu spät liest, können Millionen Systeme kompromittiert werden
    nginx hat derzeit etwa 39–43 % Marktanteil bei öffentlich zugänglichen Webservern, daher ist das ziemlich ernst

• Das hier ist ziemlich übel, hat aber Voraussetzungen
  Es ist eine rewrite-Direktive mit einem Fragezeichen im Ersetzungsstring nötig, gefolgt von einer set-Direktive, die auf eine Regex-Capture-Group verweist
  Beispiel: set $var $1
  Außerdem setzt der Proof of Concept deaktiviertes ASLR voraus

  • Beispiel: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
  • Gibt es Distributionen, bei denen ASLR standardmäßig deaktiviert ist?
    Selbst wenn man es manuell abschaltet, wäre nginx für mich nicht der naheliegende Kandidat dafür
  • Wird rewrite heutzutage nicht kaum noch verwendet?
    Das wirkt wie etwas aus den alten PHP- und Apache-Zeiten

• Hier ist die offizielle F5-Seite: https://my.f5.com/manage/s/article/K000161019
  Wie auch anderswo geschrieben wurde, schützt ASLR
  Als Mitigation, bis korrigierte Builds für die betroffenen Plattformen vorliegen, wird empfohlen, in rewrite-Definitionen benannte Captures statt unbenannter Captures zu verwenden
  Dort steht sinngemäß: „Um die Schwachstelle in diesem Beispiel zu mitigieren, ersetzen Sie $1 und $2 durch passende benannte Captures wie $user_id und $section“
  F5 hat 1.31.0 und 1.30.1 gepatcht
  OpenResty hat Patches für 1.27 und 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
  Den Fortschritt bei OpenResty, dem auf Nginx basierenden Lua-Anwendungsserver, kann man hier verfolgen: https://github.com/openresty/openresty/issues/1119

• Der Proof of Concept deaktiviert ASLR: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

  • Worker-Prozesse werden vom Master per fork erzeugt und erhalten daher das gleiche Memory Layout
    Gegen die Worker kann man unbegrenzt Crashes auslösen
    Wahrscheinlich lässt sich das nutzen, um eine Read-Oracle zu bauen
    Zumindest ist ein zuverlässiger Denial of Service möglich
    Die vollständige Analyse von Depth First: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

• Gibt es unter den guten Alternativen zu Apache und Nginx etwas, das in einer speichersicheren Sprache geschrieben ist und nicht viele Sicherheitslücken hat?
  Ich habe mir kurz Jetty in Java und Caddy in Go angesehen, aber Jetty hat eine Historie anderer Schwachstellenarten wie Shell Injection, daher bin ich nicht sicher, ob das wirklich besser ist

  • Speichersicherheit ist gut, aber sie stoppt nicht jede Bedrohung
    Infrastrukturbetreiber sollten sich heute an aktive Verteidigung durch MAC gewöhnen, also SELinux und AppArmor
    Früher war das mit mehr Reibung verbunden, aber heute gibt es mehr Werkzeuge, die die Nutzung erleichtern
    https://presentations.nordisch.org/apparmor/
    https://github.com/nobody43/apparmor-profiles/blob/master/ng...
    https://github.com/nobody43/apparmor-suggest
    Zur Einordnung: Beide Repositories stammen von mir
  • Bei Software, die in der Größenordnung von Apache und nginx eingesetzt wird, ist eine Vulnerability-Historie unvermeidlich
    Dass beide so lange ihren Marktanteil halten konnten, ist eher ein gutes Zeichen
  • Caddy war wirklich sehr angenehm zu benutzen
    Das Modell, statt eines ordentlichen Plugin-Systems je nach gewünschter Plugin-Kombination Tausende Binärdateien zu erzeugen, gefällt mir aber nicht besonders
    Wenn man aus dem Source baut, ist es trotzdem ziemlich sauber und einfach
  • Apache und vermutlich auch nginx haben unglaublich viele Features und Komponenten
    Alternative HTTP-Server reduzieren den Umfang meist stark, daher muss man zuerst entscheiden, welche Funktionen man braucht
    Ich habe nicht viele Diskussionen über HTTP-Server in speichersicheren Sprachen gesehen
    Die drei großen C-basierten Server Apache, nginx und lighttpd sind alle ziemlich solide, und es scheint nicht viele zu geben, die allein wegen der Sprache auf ein neues Projekt wechseln wollen
    Außerdem akzeptiert man bei den meisten speichersicheren Sprachen oft auch deren teils umfangreiche Runtime oder Virtual Machine samt Zubehör
    Bei einem Java-Webserver besteht die Chance, dass er log4j verwendet, wie so oft bei beliebigen Java-Projekten
  • Für Load-Balancing macht HAProxy einen sehr guten Job

• „Der Exploit verwendet request-übergreifendes Heap Feng Shui“, zum ersten Mal sehe ich feng shui in diesem Zusammenhang so verwendet

• Ist das in Debian 12 gepatcht?
  Und wenn man nirgends rewrite oder set verwendet, kann man dann davon ausgehen, dass man nicht betroffen ist?

  • https://security-tracker.debian.org/tracker/CVE-2026-42945
  • Ubuntu war heute Morgen bereits gepatcht
    Bei Debian scheint trixie noch nicht gepatcht zu sein
  • Es dürfte sehr selten sein, nginx zu verwenden, ohne wenigstens set einzusetzen
    Die meisten nginx-Anwendungsfälle terminieren TLS und leiten Anfragen an node/php/go usw. weiter
    Daher dachte ich, es gäbe wahrscheinlich irgendwo eine set-Zeile mit von Angreifern kontrollierten Daten, etwa proxy_set_header X-Host $host;
    Korrektur: Benannte Captures scheinen nicht betroffen zu sein
    Wenn es nirgendwo ein $1 gibt, sollte es in Ordnung sein

• Bessere Links:
  https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
  https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)