Security 18.05.2026 Aktualisiert: 29.06.2026

NGINX Rift CVE-2026-42945: Rewrite-Regeln prüfen und patchen

NGINX Rift betrifft Rewrite-Konfigurationen. Prüfe CVE-2026-42945, Paketstände, Plesk-Hosts, ASLR, Mitigation und Updates.

Stand: 29.06.2026, 08:45 Uhr CEST. NGINX Rift, CVE-2026-42945, ist kein “jedes NGINX ist sofort RCE”-Fall. Betroffen sind ungepatchte NGINX-Versionen mit einer bestimmten rewrite-/set-Konfiguration. Trotzdem gehört die Lücke auf produktiven Reverse Proxies, Plesk-Hosts und API-Gateways zügig geschlossen: Der Bug ist remote triggerbar, der öffentliche Write-up zeigt RCE unter passenden Bedingungen, und Mitte Mai wurden laut The Hacker News unter Berufung auf VulnCheck bereits Ausnutzungsversuche beobachtet.

Kurzfassung

Worum es geht: CVE-2026-42945 ist ein Heap-Buffer-Overflow im ngx_http_rewrite_module. Der Fehler wurde als “NGINX Rift” bekannt.
Remote erreichbar: Ja, aber nur wenn die verwundbare Rewrite-Konfiguration aktiv ist. Ein normaler HTTP-Request reicht dann als Trigger.
Typisches Muster: Eine rewrite-Direktive mit einem Fragezeichen im Replacement, danach eine weitere rewrite-, if- oder set-Direktive, die mit unbenannten PCRE-Captures wie $1 oder $2 arbeitet.
Folge: Mindestens Worker-Crash und damit Denial of Service. Codeausführung ist möglich, wenn ASLR deaktiviert ist oder umgangen werden kann. Der öffentliche Research-Post zeigt RCE mit ASLR aus.
Betroffene Upstream-Versionen: NGINX Open Source 0.6.27 bis 1.30.0. Gefixt sind 1.30.1 stable und 1.31.0 mainline oder neuer.
Distributionen: Debian, Ubuntu, RHEL und AlmaLinux haben Fixes oder Backports veröffentlicht. Rocky, Oracle, SUSE, Fedora, Alpine, Amazon Linux, CloudLinux/cPanel und Plesk müssen gegen den jeweils eigenen Paketkanal geprüft werden.
Schnelle Maßnahme: Paketupdate einspielen, nginx -t ausführen und NGINX reloaden. Wenn ein Update nicht sofort möglich ist, die betroffenen Rewrite-Regeln umbauen.
Nicht machen: Die öffentliche Exploit-Logik nicht auf Produktivsystemen testen. Ein Worker-Crash ist hier kein harmloser Scanner-Nachweis.

Was ist NGINX Rift?

NGINX Rift ist eine Speicherfehler-Lücke in der Rewrite-Logik von NGINX. Der Bug sitzt nicht in TLS, nicht in PHP-FPM und nicht in einem bestimmten Backend. Er entsteht in NGINX selbst, wenn das Rewrite-Modul eine bestimmte Kombination aus Regex-Captures und Query-String-Umschreibung verarbeitet.

Das betroffene Muster sieht vereinfacht so aus:

location ~ ^/api/(.*)$ {
  rewrite ^/api/(.*)$ /internal?migrated=true;
  set $original_endpoint $1;
}

Das Beispiel ist absichtlich klein. In echten Setups steckt das oft in API-Migrationen, Legacy-Routing, Mandantenpfaden, Weiterleitungen, Logging-Variablen oder Reverse-Proxy-Konfigurationen. Genau deshalb ist die Lücke für Hosting- und Agenturserver relevanter als eine exotische Laborkonfiguration.

Wichtig ist die Einschränkung: Ein alter NGINX allein reicht nicht. Die ausnutzbare Konfiguration muss vorhanden sein. Umgekehrt ist “wir nutzen nur NGINX als Reverse Proxy” keine Entwarnung, weil gerade Reverse-Proxies häufig mit rewrite, Captures und Query-String-Umbauten arbeiten.

Wie funktioniert die Lücke technisch?

NGINX kompiliert Rewrite- und Set-Anweisungen intern in eine Art Script-Engine. Diese Engine arbeitet bei komplexen Werten in zwei Schritten:

Sie berechnet, wie lang der Zielstring werden muss.
Sie kopiert die tatsächlichen Daten in den dafür reservierten Speicher.

Dieser Ansatz ist schnell, aber er setzt voraus, dass beide Schritte dieselbe Vorstellung davon haben, wie viele Bytes geschrieben werden. Bei CVE-2026-42945 stimmt genau das nicht.

Der kritische Teil entsteht, wenn eine rewrite-Direktive ein Fragezeichen im Replacement enthält. NGINX behandelt den Teil danach als Query String und setzt intern einen Zustand, der beim Kopieren von Capture-Werten Escaping erzwingen kann. In der Längenberechnung für eine spätere set- oder ähnliche Direktive wird dieser Zustand aber nicht genauso berücksichtigt. NGINX reserviert also Speicher für die ungeescapte Capture-Länge, schreibt später aber die escapte Variante hinein.

Aus einem Zeichen kann dabei mehr werden. Zeichen wie +, & oder andere im Query-Kontext relevante Bytes können beim Escaping größer werden. Wenn die Längenberechnung die kurze Variante annimmt, die Kopierphase aber die längere Variante schreibt, läuft der Schreibvorgang über das Ende des reservierten Puffers hinaus.

Das ist der Heap-Overflow. In der einfachen Variante stürzt ein Worker ab. In der gefährlicheren Variante kann ein Angreifer Speicherstrukturen so überschreiben, dass Code im Worker-Prozess ausgeführt wird. Der öffentliche DepthFirst-Write-up beschreibt, warum NGINX mit Master-/Worker-Prozessen und reproduzierbaren Heap-Layouts hier unangenehm ist: Ein gecrashter Worker wird neu gestartet, und die Speicherlage bleibt für wiederholte Versuche oft ähnlich genug.

Das ist bewusst keine Exploit-Anleitung. Für Betrieb und Patchplanung reicht der entscheidende Punkt: Die Lücke wird durch eine bestimmte Rewrite-Konfiguration remote getriggert. Ob daraus “nur” Worker-Crashes oder RCE wird, hängt von Härtung, ASLR, Build, Modulen, Speicherschutz und Ausnutzbarkeit im konkreten Setup ab.

Wer ist betroffen?

Betroffen sind NGINX-Installationen mit verwundbarer Version und passender Konfiguration. Dazu zählen auch Produkte und Plattformen, die NGINX einbetten oder paketieren.

Umgebung	Einschätzung	Worauf prüfen
NGINX Open Source von nginx.org	Upstream verwundbar von `0.6.27` bis `1.30.0`; gefixt ab `1.30.1` stable und `1.31.0` mainline.	`nginx -v`, Paketquelle und Changelog prüfen.
NGINX Plus	DepthFirst nennt NGINX Plus R32 bis R36 als betroffen. Die genauen Fixstände hängen vom F5-Maintenance-Release ab.	F5-Advisory K000161019 und installierte Plus-Version prüfen.
Debian	Security-Fixes sind für Bullseye, Bookworm und Trixie verfügbar; Forky/Sid sind ebenfalls gefixt.	Debian Security Tracker und installierte `nginx`-Pakete prüfen.
Ubuntu	Canonical nennt fixe Versionen für 26.04, 25.10, 24.04 und 22.04; ältere LTS-Stände laufen über Ubuntu Pro/ESM.	Ubuntu-CVE-Seite, `apt-cache policy nginx` und laufendes Paket prüfen.
RHEL	Red Hat hat RHSA-Fixes für RHEL 8, 9, 10 und mehrere EUS/E4S/AppStream-Pfade veröffentlicht.	Red-Hat-CVE-Seite, AppStream-Modul und `rpm -q nginx` prüfen.
AlmaLinux	AlmaLinux hat eigene Fixes für AL8, AL9 und AL10 veröffentlicht.	AlmaLinux-Advisory und Modulstream prüfen, nicht nur die Hauptversion.
Rocky Linux	Rocky folgt nicht immer zeitgleich jedem RHEL-/Alma-Modulstream. Ende Mai waren einzelne NGINX-Streams sichtbar noch Thema.	Rocky Errata oder `dnf updateinfo` gegen den konkreten Stream prüfen.
SUSE / openSUSE	SUSE führt produktgenaue Fixstände; Tumbleweed und mehrere SLE-Varianten haben eigene Paketstände.	SUSE-CVE-Seite pro Produkt und Service Pack prüfen.
Alpine	Alpine/OSV führt Fixes für `nginx`, unter anderem `1.28.3-r1` und `1.30.1-r0` je nach Branch.	`apk version -v nginx` und Alpine Advisory prüfen.
Amazon Linux	Amazon Linux listet `nginx`-Fixes für Amazon Linux 2 Nginx1 Extra und Amazon Linux 2023.	ALAS2NGINX1-2026-012 und ALAS2023-2026-1714 prüfen.
Fedora	Fedora/Bodhi hat NGINX-Updates nachgezogen.	Bodhi-Update, `dnf updateinfo info nginx` und installierte Version prüfen.
CloudLinux / cPanel / EasyApache	NGINX kann über OS-Pakete, CloudLinux- oder cPanel/EasyApache-Kanäle kommen.	Nicht nur `rpm -q nginx`, sondern auch `ea-nginx`/EasyApache und CloudLinux-Changelogs prüfen.
Plesk	Plesk nutzt NGINX häufig als Reverse Proxy. Die Lücke sitzt aber im NGINX-Paket, nicht im Kunden-PHP.	Plesk-KB, OS-Vendor-Pakete und Plesk-eigene Updates prüfen.
Container-Images	Ein Container bringt seine eigene NGINX-Binary mit. Anders als bei Kernel-CVEs zählt hier nicht nur der Host.	Base-Image neu bauen, Image-Scanner nicht als einzigen Nachweis verwenden.

Patchstände nach Distribution

Die folgende Tabelle ist eine Momentaufnahme. Bei Distributionspaketen zählt der Backport deines Vendors, nicht nur die sichtbare Upstream-Version.

Distribution / Plattform	Stand zum geprüften Zeitpunkt
NGINX Open Source	Gefixt ab `1.30.1` stable und `1.31.0` mainline.
Debian Bullseye	Security-Paket aktuell `1.18.0-6.1+deb11u7`, Status fixed. Der minimale DLA-Fix begann bei `1.18.0-6.1+deb11u6`.
Debian Bookworm	Security-Paket aktuell `1.22.1-9+deb12u8`, Status fixed. Der minimale DSA-Fix begann bei `1.22.1-9+deb12u7`.
Debian Trixie	Security-Paket aktuell `1.26.3-3+deb13u6`, Status fixed. Der minimale DSA-Fix begann bei `1.26.3-3+deb13u5`.
Debian Forky / Sid	Gefixt ab `1.30.0-3`, aktuell im Tracker `1.30.1-6`.
Ubuntu 26.04 LTS	`nginx` gefixt ab `1.28.3-2ubuntu1.1`.
Ubuntu 25.10	`nginx` gefixt ab `1.28.0-6ubuntu1.3`.
Ubuntu 24.04 LTS	`nginx` gefixt ab `1.24.0-2ubuntu7.8`.
Ubuntu 22.04 LTS	`nginx` gefixt ab `1.18.0-6ubuntu14.11`.
Ubuntu 20.04 / 18.04	Fixes über Ubuntu Pro/ESM, unter anderem `1.18.0-0ubuntu1.7+esm1` und `1.14.0-0ubuntu1.11+esm2`.
RHEL 8	RHSA-2026:18041, `nginx:1.24-8100020260514165201.489197e6`.
RHEL 9	Unter anderem `nginx-2:1.20.1-24.el9_7.3`, zusätzlich Modulstreams `nginx:1.24` und `nginx:1.26` mit eigenen RHSA-Fixes.
RHEL 10	Unter anderem `nginx-2:1.26.3-2.el10_1.2` beziehungsweise `1.26.3-6.el10_2.3`.
AlmaLinux 8	AlmaLinux nennt als Fixziel den NGINX-1.24-Modulstream passend zu RHEL 8.10.
AlmaLinux 9	AlmaLinux nennt Fixes für `nginx-1.20.1-24.el9_7.3` sowie die Modulstreams `nginx:1.24` und `nginx:1.26`.
AlmaLinux 10	AlmaLinux nennt `nginx-1.26.3-2.el10_1.2` als Fixstand für AL10.
SUSE / openSUSE	SUSE führt produktgenaue Stände, etwa `nginx >= 1.21.5-150600.10.18.1` für mehrere SLE-15-SP7-Pfade, `1.27.2-160000.4.1` für SLES/Leap 16.0 und `1.31.0-1.1` für openSUSE Tumbleweed.
Alpine	Alpine/OSV nennt Fixes je nach Branch, unter anderem `1.28.3-r1` und `1.30.1-r0`.
Amazon Linux	Amazon Linux meldet Fixes am 26.05.2026 für Amazon Linux 2 Nginx1 Extra und Amazon Linux 2023.

Bei Plesk-, cPanel-, Container- und Appliance-Setups ist die Paketfrage oft zweigeteilt: Es kann ein OS-NGINX laufen, ein vom Panel verwalteter NGINX oder ein NGINX in einem Container-Image. Prüfe deshalb zuerst, welche Binary wirklich Traffic annimmt.

Schnelle Prüfung auf einem Host

Zuerst brauchst du Version und Build-Pfad:

nginx -v
nginx -V 2>&1
command -v nginx

Auf Debian, Ubuntu und Plesk-nahen Systemen:

dpkg -l 'nginx*' 'plesk-nginx*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
apt-cache policy nginx nginx-full nginx-core nginx-extras 2>/dev/null

Auf RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahen Systemen:

rpm -q nginx nginx-core nginx-filesystem ea-nginx 2>/dev/null
dnf updateinfo info nginx 2>/dev/null || true
dnf module list nginx 2>/dev/null || true

Auf SUSE und openSUSE:

zypper se -si 'nginx*'
zypper patches --cve=CVE-2026-42945 2>/dev/null || true

Auf Alpine:

apk version -v nginx
apk info -vv nginx

Dann kommt die Konfigurationsprüfung. nginx -T gibt die komplette geladene Konfiguration aus. Das kann Hostnamen, Pfade und manchmal interne Details enthalten. Also nicht blind in Tickets oder Chats kippen.

sudo nginx -T 2>/tmp/nginx-config.err \
  | grep -nE 'rewrite .*\\?.*|set .*\\$[0-9]+|if .*\\$[0-9]+'

Dieser Grep ist nur ein Startpunkt. Er findet Verdachtsstellen, keine vollständige statische Analyse. Du musst prüfen, ob eine rewrite-Direktive mit Fragezeichen im Replacement von einer rewrite-, if- oder set-Direktive mit $1, $2 und ähnlichen unbenannten Captures gefolgt wird.

Beispiele für prüfenswerte Stellen:

rewrite ^/old/(.*)$ /new?path=$1;
set $backend_path $1;

rewrite ^/(.*)$ /index.php?route=$1;
if ($1) {
  set $route $1;
}

Nicht jede solche Zeile ist automatisch ausnutzbar, aber sie gehört manuell bewertet. Besonders kritisch sind öffentliche Locations, die lange oder stark escapbare Pfade annehmen.

Updates und Mitigation

Die saubere Lösung ist ein NGINX-Update aus deinem Paketkanal. Danach muss die Konfiguration getestet und der Dienst reloadet werden.

sudo nginx -t
sudo systemctl reload nginx

Wenn NGINX nicht über systemd läuft, nutze den Dienstweg deiner Plattform. Bei Plesk, cPanel, Kubernetes Ingress, Container-Images oder Appliances kann das ein eigener Reload- oder Rollout-Pfad sein.

Wenn ein Update nicht sofort möglich ist, bleibt als Übergang nur die Konfiguration zu entschärfen:

betroffene rewrite-Regeln ohne Fragezeichen im Replacement umbauen
unbenannte Captures $1, $2 in nachgelagerten set-, if- oder rewrite-Direktiven vermeiden
Weiterleitungen mit return 301/return 302 lösen, wenn kein komplexes Rewrite nötig ist
Query-String-Logik in map oder Backend-Code verlagern, wenn sie in NGINX zu verschachtelt wird
verdächtige Legacy-Regeln entfernen, statt sie nur mit Kommentaren zu erklären

ASLR sollte aktiv sein:

sysctl kernel.randomize_va_space

Ein Wert von 2 ist auf normalen Linux-Servern üblich. Das ist aber keine echte Mitigation gegen den Bug. ASLR senkt die Chance auf Codeausführung, verhindert aber nicht Worker-Crashes und ersetzt keinen Patch.

Wenn du vorübergehend mit WAF- oder CDN-Regeln arbeiten musst, behandle das nur als Zusatz. Die Lücke sitzt in der NGINX-Konfiguration und der NGINX-Binary. Ein Regex am Rand kann offensichtliche Requests abfangen, aber nicht zuverlässig alle nutzbaren Varianten.

Was beim Patchen gern übersehen wird

Der erste Fehler ist der falsche NGINX. Auf einem Plesk- oder cPanel-Host kann ein anderer NGINX laufen als der, den apt oder dnf zuerst zeigt. In Containern gilt dasselbe: Das Host-Paket kann sauber sein, während ein altes NGINX-Image weiter Traffic bedient.

Der zweite Fehler ist ein Reload ohne Test. NGINX-Pakete lassen sich leicht aktualisieren, aber alte Konfigurationen können nach einem Versionswechsel Warnungen oder Fehler werfen. nginx -t gehört vor den Reload.

Der dritte Fehler ist eine rein versionsbasierte Entwarnung bei Vendor-Kerneln und Vendor-Paketen. Ein Debian- oder RHEL-Paket mit alter Upstream-Hauptversion kann durch Backports gefixt sein. Umgekehrt kann ein selbst gebautes 1.30.0 aus einer alten Quelle verwundbar bleiben, obwohl die Distribution längst ein gefixtes Paket anbietet.

Der vierte Fehler ist, nur die Standardseite zu prüfen. Rewrite-Regeln liegen oft in Include-Dateien, Panel-generierten Snippets, Kunden-vHosts, Ingress-Templates oder alten Migrationsresten.

Der fünfte Fehler ist, Worker-Crashes als harmlos abzutun. Wiederholte signal 11, unerklärliche Worker-Restarts oder kurze 502-Wellen auf einem ungepatchten NGINX mit passender Rewrite-Konfiguration gehören untersucht.

Einordnung für produktive Systeme

Für produktive Systeme ist NGINX Rift vor allem dort kritisch, wo NGINX direkt am Internet hängt und viel Konfiguration trägt: Reverse Proxies, API-Gateways, Plesk-Hosts, Multi-Tenant-Webserver, Kubernetes-Ingress-Controller und alte Migrationssetups.

Auf einer simplen statischen NGINX-Seite ohne Rewrite-Regeln ist das Risiko deutlich geringer. Patchen solltest du trotzdem, weil NGINX-Releases im Mai mehrere weitere Sicherheitsfixes enthielten. Außerdem ändern sich Konfigurationen oft schneller als Inventarlisten.

Bei Plesk- und Hosting-Systemen ist die Reihenfolge pragmatisch:

Herausfinden, welche NGINX-Binary aktiv ist.
Paketstand gegen OS-, Plesk- oder Panel-Quelle prüfen.
nginx -T nach Rewrite-/Capture-Mustern durchsuchen.
Wenn betroffen: Update oder kurzfristige Regeländerung.
nginx -t, Reload, Monitoring auf Worker-Restarts und 4xx/5xx prüfen.
Container-Images und Ingress-Controller separat bewerten.

Wenn du nicht sicher bist, welcher NGINX auf deinen Systemen tatsächlich am Traffic hängt, ist ein kurzer Security- und Webserver-Check sinnvoller als ein blindes Paketupdate. Gerade bei Panels, Ingress-Controllern und Reverse-Proxies steckt die eigentliche Wahrheit oft in Includes, Templates und Deployment-Pipelines.

Update-Log

Dieses Log hält die reale Disclosure- und Vendor-Lage fest.

2026-04-18: DepthFirst analysierte den NGINX-Code intern und fand mehrere Speicherfehler, darunter den später als CVE-2026-42945 geführten Rewrite-Bug.
2026-04-21: Die Findings wurden über eine GitHub Security Advisory an NGINX gemeldet.
2026-04-24: NGINX bestätigte laut DepthFirst vier der gemeldeten Issues.
2026-04-28: DepthFirst informierte NGINX, dass ein funktionierender RCE-PoC existiert.
2026-05-05: Der RCE-PoC samt Demo wurde laut Timeline an NGINX geteilt.
2026-05-13: F5 veröffentlichte das Advisory K000161019. NGINX veröffentlichte 1.30.1 stable und 1.31.0 mainline mit Fixes für CVE-2026-42945 und mehrere weitere CVEs.
2026-05-13: DepthFirst veröffentlichte den technischen NGINX-Rift-Write-up. Die oss-security-Liste griff das Advisory noch am selben Tag auf.
2026-05-14 bis 2026-05-19: Red Hat, Ubuntu, AlmaLinux, Debian und weitere Vendor-Tracker veröffentlichten oder aktualisierten Paketstände und Backports.
2026-05-18: The Hacker News berichtete unter Berufung auf VulnCheck über Ausnutzungsversuche gegen CVE-2026-42945. Damit war die Lücke nicht mehr nur ein Research-Thema.
2026-05-22: NGINX veröffentlichte 1.30.2 und 1.31.1 für CVE-2026-9256, eine separate Rewrite-Module-Lücke. Das ist nicht derselbe CVE, aber für Wartungsfenster im selben Bereich relevant.
2026-06-29: Artikel mit Debian-, Ubuntu-, Red-Hat-, AlmaLinux-, SUSE-, Alpine- und Amazon-Linux-Ständen nachgezogen und den Plesk-/Panel-Hinweis ergänzt.