Die vergangenen Tage ist die kritische Schwachstelle CVE-2026-42945 in der Software NGINX öffentlich geworden. Hatte ich aus bestimmten Gründen (auch weil eine Ausnutzung nur bei abgeschaltetem ASLR möglich ist) bisher im Blog nicht aufgegriffen. Ich trage nun einige Informationen zusammen, da es inzwischen eine aktive Ausnutzung dieser Schwachstelle gibt. Ergänzung vom 19.5.2026: POC zur Ausnutzung mit aktivem ASLR bekannt geworden.
Was ist NGINX?
NGINX ist ein populärer und breit eingesetzter Open Source Webserver, der auch als Reverse-Proxy, Load Balancer, Mail-Proxy und HTTP-Cache eingesetzt werden kann. Die Software wurde vom russischen Entwickler Igor Sysoev entwickelt und 2004 veröffentlicht. Ein großer Teil der Webserver nutzt NGINX, häufig als Lastverteiler.
Die NGINX-Schwachstelle (CVE-2026-42945)
Die Information über die Schwachstelle CVE-2026-42945 wurde so um den 13. Mai 2026 öffentlich. Nachfolgender Tweet fasst die Kernpunkt zusammen.
Bei der NGINX Schwachstelle CVE-2026-42945 handelt es sich um einen Heap-Pufferüberlauf im ngx_http_rewrite_module von NGINX. Denkbar sind Denial of Service-Angriffe (DOS). Im schlimmsten Fall ermöglicht die Sicherheitslücke eine Remote Code-Ausführung.
Die Schwachstelle ist seit 2008 im Code vorhanden und wurde mit einem CVSS 3.1-Score von 9.2 bewertet. Betroffen sind NGINX 0.6.27 bis 1.30.0, NGINX Plus R32–R36, Ingress Controller 3.5–5.4.x, Gateway Fabric, F5 WAF, App Protect. Entdeckt wurde die Schwachstelle von Zhenpeng (Leo) Lin bei DepthFirst AI mithilfe ihres autonomen Code-Analysesystems. Eine ausführliche Beschreibung findet sich im DepthFirst-Artikel NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability.
RedHat hat beispielsweise eine Sicherheitswarnung veröffentlicht – auch von anderen Linux-Distributionen wie Debian etc., die NGINX enthalten, gibt es Warnungen. Eine Zusammenfassung findet sich auch hier. Allerdings hatte ich die Tage bereits auf X die Anmerkung gesehen, dass eine Ausnutzung der Schwachstelle nur mit ausgeschaltetem ASLR gegeben sei – und ASLR sollte bei NGINX standardmäßig eingeschaltet sein. Plesk hat diesen Artikel veröffentlicht, der auch Hinweise enthält, um zu prüfen, ob die Version angreifbar ist und ob ASLR deaktiviert wurde.
Die Schwachstelle (CVE-2026-42945) wird ausgenutzt
Nachfolgender Tweet weist darauf hin, dass 19 Millionen NGINX-Instanzen im Internet gefunden wurden. Dabei finden sich fast 1,8 Millionen Instanzen in Deutschland. Der Tweet weist aber darauf hin, dass nicht ab allen Instanzen ASLR deaktiviert sei.
Auf GitHub gibt es inzwischen einen Exploit für CVE-2026-42945. Da es im Blog bereits kurz angesprochen wurde und es inzwischen Versuche zur Ausnutzung gibt, habe ich das Thema aufgegriffen. The Hacker News greift es in nachfolgendem Tweet und im Beitrag NGINX CVE-2026-42945 Exploited in the Wild, Causing Worker Crashes and Possible RCE auf.
Angreifer können Worker mit einer einzigen Anfrage (siehe diesen Tweet) zum Absturz bringen, falls kein ASLR aktiviert ist.
Ergänzung: Zum 19.5.2026 habe ich die Information bekommen, dass ein Proof of Concept (PoC) zur Ausnutzung mit aktivem ASLR bekannt veröffentlicht wurde.
MVP: 2013 – 2016
Debian / Ubuntu haben am 14.05. schon fixes erhalten. Einfach mal updaten, falls noch nicht geschehen, dann sollte man im Idealfall versorgt werden :)
Wunderbar. Was ist vor allem mit den ganzen Diensten, die einen Ngnix intern verbaut haben oder zumindest mitbringen (3CX, pfsense usw.) Bei pfsense bin ich noch ganz entspannt, da es nur intern offen sein sollte…
Die spannende Frage ist, ob diese Dienste dann an ASLR rumfuhrwerken und das deaktivieren …
Nicht wenn du NGiNX als reverse Proxy verwendest um interne Dienste zum Internet zu öffnen.
Interessant sind auch Container, Softwareentwickler liefern gerne mal in Ihren Kompositionen gammlige Container aus oder aktualisieren abhängige Container nur wenn das eigene Produkt mal ein Update bekommt. Sowas übersieht man schneller mal als ein natives NGiNX Paket auf einer Linux Kiste.
freebsd hat auch schon den fix. müssten dann pfsense / opnsense einspielen.
Ist NGINX wirklich noch so verbreitet? In Tagen von Docker und Containern würde ich heute eher HAProxy, Traefik oder Caddy erwarten.
Nö, Du hast Recht, absolute Nische – laut obigem Tweet sind nur schlappe 19 Millionen Systeme erfasst worden … ;-)
PS: Und im Gegensatz zum ESC liegt Germany weltweit mit 1,87 Millionen Systemen auf Platz 3.
@Anonym
Ja, das Ding ist extrem weit verbreitet und teilweise extrem tief in Systemen integriert. Genau so wie Apache2. Wenn es in diesen Produkten Sicherheitslücken gibt, dann sieht man ja, wie schnell die verwundbaren Hosts in die Höhe schnellen…
Und wohin leiten diese Proxys in 99% der Fälle?
Richtig, zu Webservern, die die Anfragen verarbeiten.
Da tummeln sich allein bei meinen beiden öffentlichen traefik Instanzen so einige nginx Server hinter dem Proxy.