NGINX Rift CVE-2026-42945 — wie eine 18 Jahre alte Annahme im Rewrite-Modul den Reverse-Proxy zerreißt

TL;DR — 90 Sekunden

Eine 18 Jahre alte Annahme im NGINX-Rewrite-Modul lässt einen einzigen gecrafteten HTTP-Request einen Worker-Crash auslösen, mit ASLR-Off ist potenzieller RCE möglich. Der Patch ist seit zwei Tagen da, die Konfigurations-Disziplin im NGINX-Bestand ist die zweite, nachhaltigere Mitigation.

Was ist das Problem?

NGINX' ngx_http_rewrite_module setzt URLs nach Regex-Pattern um. Eine typische Konfiguration sieht so aus: rewrite ^/old/(.+)$ /new/$1?token=abc; — die unbenannte Capture $1 greift den ersten Capture-Block aus dem Regex und setzt ihn in das Replacement-String. Das Fragezeichen markiert den Beginn des Query-Strings im Replacement.

Der Sicherheitspfad sitzt in der Zweistufigkeit des Buffer-Handlings. NGINX berechnet die nötige Buffer-Größe für das fertige Replacement-String mit einem ersten Escaping-Pass. Anschließend schreibt NGINX das Replacement mit einem zweiten Escaping-Pass in den allokierten Buffer — mit einer leicht abweichenden Set an Sonderzeichen.

Wenn das Replacement Zeichen wie +, % oder & enthält und auf eine weitere Direktive (rewrite, if, set) trifft, die das Replacement noch einmal verarbeitet, expandiert das Re-Escape den String — + wird zu %20, & wird zu &, und der Write-Pfad schreibt mehr Bytes als der Sizing-Pfad allokiert hat. Der Buffer-Overflow läuft in den Heap-Bereich hinter dem Allokations-Ende.

Die Analyse von Picus Security führt den Pfad bis ins Detail: die Berechnung erfolgt in ngx_http_script_regex_end_code() mit ngx_escape_uri(NULL, ...), der Write in ngx_http_script_complex_value_code() mit ngx_escape_html(NULL, ...). Beide Funktionen sind in NGINX seit 0.6.27 (2008) so implementiert; die Diskrepanz im Sonderzeichen-Set hat 18 Jahre lang nicht zu einer Sicherheitslücke geführt, weil typische Konfigurationen entweder keine unbenannte Capture mit Fragezeichen-Replacement nutzen, oder weil die Folge-Direktive den Re-Escape nicht ausgelöst hat.

Das ist die strukturelle Lehre: kein neuer Code-Pfad, sondern eine alte Annahme über Konsistenz zwischen zwei internen Funktionen, die für eine bestimmte Konfigurations-Klasse erst durch die Kombination dreier Bedingungen scharfgestellt wird (unbenannte Capture + Fragezeichen + Folge-Direktive). Der Exploit-PoC im öffentlichen Repository auf GitHub zeigt die Reproduktion in fünf Zeilen Konfiguration und einem curl-Aufruf.

Wer ist betroffen?

Eine kompakte Übersicht über betroffene und nicht betroffene Konstellationen.

Wer im DACH-Mittelstand TYPO3- oder Sylius-Plattformen über einen NGINX-Reverse-Proxy auf Hetzner-Cloud, Hetzner-Dedicated, AWS-EC2 oder Azure-VM-Bestand fährt, ist im Standard betroffen — der Anteil der Plattformen ohne rewrite-Direktive im NGINX-Pfad ist im DACH-Korpus klein. Wir behandeln den Bestand operativ als „NGINX patchen und Konfig linten“ und gehen nach Audit-Pfad vor: erst Konfigurations-Lint, dann Versions-Audit, dann Patch im Wartungsfenster.

Auswirkungen

Die operative Schwere bestimmt sich aus drei Faktoren: dem Trigger-Aufwand (unauthenticated, ein HTTP-Request), der Exposition-Fläche (NGINX als Front-Edge) und der Exploit-Realisierungs-Stufe (Worker-Crash garantiert, RCE bedingt).

Der Trigger-Aufwand ist niedrig. Der Angreifer braucht keinen Account, keine Session, keinen Token. Ein einzelner HTTP-Request gegen einen Pfad, der unter eine vulnerable rewrite-Direktive fällt, reicht. Das macht den Befund anders als beim Composer-Token-Leak (lokales Pipeline-Detail) und beim node-ipc-Vorfall (lokales Build-Pipeline-Detail): NGINX-Rift sitzt auf der Internet-exponierten Frontline.

Die Exposition-Fläche ist breit. NGINX bedient nach den letzten verfügbaren W3Techs-Schätzungen einen niedrigen 30er-Prozentbereich der globalen Webserver-Last und ist im DACH-Mittelstand-PHP-Bestand der häufigste Reverse-Proxy vor TYPO3/Sylius. Das eigentliche Verbreitungsmuster sind nicht die NGINX-Standalone-Hosts, sondern die NGINX-Konfigurations-Vorlagen im Plattform-Bestand, die mehrheitlich rewrite-Direktiven mit unbenannten Captures verwenden — der Standard-Pfad ist rewrite ^/old/(.+)$ /new/$1?token=..., und der Token-Pattern enthält Sonderzeichen wie + oder &.

Die Exploit-Realisierungs-Stufe ist asymmetrisch. Worker-Crash ist garantiert: der Heap-Overflow trifft beim aktuellen Worker, NGINX startet den Worker automatisch neu, aber der Crash ist nachweisbar und kostet Verfügbarkeit. RCE ist bedingt: auf Hosts mit deaktiviertem ASLR ist die Heap-Spray-Technik aus dem PoC-Repository direkt durchführbar, auf Hosts mit aktivem ASLR ist die Ausnutzung deutlich aufwändiger. Im DACH-Mittelstand-Bestand ist ASLR auf modernen Linux-Distros (Debian 12+, RHEL 9+, Ubuntu 22.04+) im Default aktiv; auf älteren Bestands-Hosts (Debian 10/11, CentOS 7, Ubuntu 18.04) ist die Konfiguration uneinheitlich.

Geschäftliche Auswirkungen einer ausgenutzten Lücke auf einer Mandanten-Plattform sind im Worst Case die Front-Edge-Übernahme: wer NGINX-Worker-RCE bekommt, sitzt auf dem TLS-Endpunkt, auf der Reverse-Proxy-Schicht und damit oberhalb der Mandanten-PHP-Schicht. Das ist der Vorlauf für Man-in-the-Middle gegen Mandanten-Benutzer, persistente Backdoor-Installation im NGINX-Konfigurationspfad, oder lateral movement in das dahinter liegende PHP-Backend. Im einfacheren Fall ist der Wirkungsraum eine wiederkehrende DoS-Welle, die den Mandanten-Plattform-Betrieb stört, ohne den Backend-Stack zu kompromittieren.

Mitigation / Sofortmaßnahmen

Drei Pfade je nach Plattform-Disziplin.

Pfad 1 — Patch auf die gefixte Linie

Distributions-Patches sind seit 13.05.2026 ausgerollt. AlmaLinux hat die gepatchte Linie im Testing-Channel, Debian-Sec-Updates laufen, NGINX Plus liefert direkt über das offizielle Repo.

# Debian / Ubuntu — Sicherheits-Update mit Distro-Backport
sudo apt update
sudo apt install --only-upgrade nginx
nginx -v
# erwartet: nginx version: nginx/1.30.1 (oder Distro-Backport-Stand)

# RHEL / AlmaLinux / Rocky — über das nginx-Stream-Modul
sudo dnf module reset nginx
sudo dnf module enable nginx:1.30
sudo dnf update nginx

# NGINX Plus über das offizielle Repo
sudo apt update
sudo apt install nginx-plus
nginx -v
# erwartet: nginx version: nginx/1.27.5 (nginx-plus-r36-p1)

Nach dem Update den NGINX-Service neu laden, nicht restartieren — reload lässt die offenen Verbindungen sauber zu Ende laufen, während die neuen Worker bereits mit dem Patch starten.

sudo systemctl reload nginx
# oder
sudo nginx -s reload

Pfad 2 — Konfigurations-Lint auf die Trigger-Bedingungen

Der Patch schließt den Code-Pfad, aber die strukturelle Anfälligkeit bleibt in der Konfiguration. Eine rewrite-Direktive mit unbenannter Capture, Fragezeichen-Replacement und Folge-Direktive ist auch nach dem Patch ein fragiler Konfigurations-Pfad, der vergleichbare Befunde in der Zukunft auslösen könnte. Linting in der Plattform-Vorlage ist die nachhaltigere Mitigation.

# Suche nach dem riskanten Pattern in allen NGINX-Konfigurationsdateien
sudo grep -rEHn 'rewrite.*\$[0-9]+.*\?' /etc/nginx/ \
  | grep -v '^[[:space:]]*#'

Im Treffer-Fall die unbenannte Capture ($1, $2) durch eine benannte Capture mit (?<name>…)-Syntax ersetzen.

# Vorher (riskant)
location /old/ {
    rewrite ^/old/(.+)$ /new/$1?token=abc;
}

# Nachher (linting-fest)
location /old/ {
    rewrite ^/old/(?<path>.+)$ /new/$path?token=abc;
}

Benannte Captures laufen durch beide Escaping-Funktionen identisch — der Sizing-Pfad und der Write-Pfad sind konsistent, der Heap-Overflow-Pfad ist geschlossen.

Pfad 3 — WAF-Schicht als Schutzlinie für unpatched Hosts

Wenn der Patch nicht im 24h-Wartungsfenster möglich ist (z. B. weil eine Plattform-Migration läuft), lässt sich die Trigger-Bedingung auf der WAF-Schicht entschärfen. Das PoC-Repository zeigt einen spezifischen Request-Pattern, der die Exploit-Kette auslöst. Eine WAF-Regel auf den Cloudflare-Edge, AWS WAF oder ModSecurity-Front kann Requests mit auffälligen Pfad-Parametern (+, %, & in URL-Pfad-Segmenten plus Query-String-Manipulation) abfangen.

# Beispiel: ModSecurity-Regel als Stopgap
SecRule REQUEST_URI "@rx (\+|\%|\&).*\?.*\$" \
    "id:90042945,phase:1,deny,log,msg:'CVE-2026-42945 trigger pattern',\
     tag:'CVE-2026-42945'"

WAF-Schicht ist kein Ersatz für den Patch. Sie fängt das aktuell bekannte Exploit-Pattern auf, aber nicht zwingend zukünftige Varianten der gleichen Klasse. Sie kauft Zeit, bis das Wartungsfenster durch ist.

Detection / Prüfung

Drei komplementäre Pfade.

Pfad 1 — Versions-Audit über den NGINX-Bestand

Erste Schicht: Versions-Inventur über den gesamten Mandanten-Bestand.

# Über Ansible, Puppet oder ein eigenes Audit-Skript die nginx-Version auf allen Hosts sammeln
ansible all -m shell -a "nginx -v 2>&1" --become

# Treffer auf unpatched Versionen herausfiltern
ansible-playbook nginx-version-audit.yml \
  --extra-vars "fail_below=1.30.1"

Für Kubernetes-Ingress-Bestand zusätzlich die Ingress-Controller-Image-Tags prüfen:

# ingress-nginx Image-Version auf allen Clustern
kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.spec.containers[0].image}{"\n"}{end}'

# erwartet: registry.k8s.io/ingress-nginx/controller:v1.13.x oder neuer

Pfad 2 — Konfigurations-Audit auf das Trigger-Pattern

Die zweite Schicht ist der Konfigurations-Lint aus dem Mitigation-Pfad 2 — aber als systematisches Audit über den gesamten NGINX-Bestand, nicht als Einzel-Host-Lauf.

# Audit-Skript über alle NGINX-Hosts der Plattform
for host in $(ansible-inventory --list | jq -r '.all.hosts[]'); do
  echo "## Host: $host"
  ssh "$host" "sudo grep -rEHn 'rewrite.*\\\$[0-9]+.*\\?' /etc/nginx/ 2>/dev/null \
    | grep -v '^[[:space:]]*#' | head -20"
done

Treffer-Hosts in eine separate Patch-Cohort einsortieren — die brauchen Patch plus Konfigurations-Lint, nicht nur Patch.

Pfad 3 — Access-Log-Audit auf Exploit-Pattern

Wenn die Plattform Access-Logs mit Query-String-Erhalt fährt (Standard für TYPO3- und Sylius-Plattformen mit Mandanten-Audit-Pflicht), lässt sich rückblickend auf das Exploit-Pattern prüfen.

# Access-Log-Suche auf die typischen Exploit-Pattern
sudo grep -E '"[A-Z]+ [^"]*[\+\%\&][^"]*\?[^"]*HTTP' /var/log/nginx/access.log \
  | awk '{print $1, $4, $5, $7}' \
  | sort -u

Pfad 4 (optional) — Falco-Rule für NGINX-Worker-Crashes

Worker-Crashes durch den Heap-Overflow erscheinen im dmesg- und im NGINX-Error-Log. Eine Falco-Rule fängt den Zusammenhang auf.

# /etc/falco/rules.d/nginx-rift-detection.yaml
- rule: NGINX worker process killed by signal SEGV
  desc: NGINX worker exited with SIGSEGV — possible CVE-2026-42945 exploitation
  condition: >
    spawned_process and
    proc.pname = "nginx" and
    proc.exepath endswith "nginx" and
    evt.type = procexit and
    proc.exitcode = -11
  output: >
    NGINX worker SIGSEGV: pid=%proc.pid cmdline=%proc.cmdline
  priority: WARNING
  tags: [nginx, cve-2026-42945, segfault]

Die Reproduktion ist im öffentlichen Repository auf GitHub dokumentiert. Fünf Zeilen Konfiguration, ein curl-Aufruf, ein Worker-Crash. Auf einem isolierten Test-Host (separate VM, kein Mandanten-Traffic, ASLR explizit deaktiviert für den vollen Pfad oder aktiv für den DoS-Pfad) lässt sich der Befund nachvollziehen. Nicht auf einem produktiv genutzten NGINX laufen lassen — der Worker-Crash zieht offene Mandanten-Verbindungen mit ab.

Betreiberempfehlung

Die operative Frage ist nicht „patchen wir auf 1.30.1?“ sondern „in welchem Wartungsfenster und in welcher Reihenfolge?“. Der Patch ist seit zwei Tagen verfügbar, der PoC ist seit gestern öffentlich — das Zeitfenster für unbemerkte Mass-Exploitation öffnet sich heute, Freitag, mit dem Wochenende vor der Tür.

Operational Decision Block — Sofort-Patch vs. Konfig-Lint

• Sofort patchen, wenn die NGINX-Konfiguration eine rewrite-Direktive mit unbenannter Capture ($1, $2) plus Fragezeichen plus Folge-Direktive enthält und der Host internet-exponiert ist.
• WAF-Stopgap einsetzen, wenn das Wartungsfenster für den Patch nicht innerhalb der nächsten 48 Stunden liegt — die WAF-Regel aus Mitigation-Pfad 3 schützt für einen begrenzten Zeitraum.
• Konfig-Lint plus Patch im Standardzyklus, wenn die NGINX-Konfiguration ausschließlich benannte Captures oder gar keine Rewrite-Direktiven mit Captures verwendet — der Patch bleibt trotzdem Pflicht, das Wartungsfenster kann in den Standard-Wochenrhythmus passen.
• Reine Awareness, wenn die Plattform NGINX ausschließlich für TLS-Termination ohne Rewrite-Direktiven nutzt und das Backend (Apache, Caddy, eigenes PHP-FPM-Listener-Setup) den Pfad selbst behandelt.

Mittelstand

Patch auf nginx 1.30.1 über den Distro-Patch-Mechanismus (apt, dnf) im Standard-Wochen-Wartungsfenster. Konfigurations-Lint über die Mandanten-NGINX-Konfigurationen — unbenannte Captures durch benannte ersetzen, Fragezeichen-Replacements auf Konsistenz prüfen, set-Direktiven nach rewrite auf strukturelle Notwendigkeit prüfen. Linting-Regel in der Plattform-Konfigurations-Vorlage ergänzen, damit zukünftige Mandanten-Konfigurationen das Pattern nicht wieder einführen. WAF-Schicht (Cloudflare, AWS WAF, ModSecurity) als Stopgap nur dann aktivieren, wenn der Patch sich um mehr als 48 Stunden verzögert.

Enterprise

Zusätzlich zur Mittelstand-Linie: Pre-Receive-Hook auf dem zentralen NGINX-Konfigurations-Repository, der unbenannte Captures mit Fragezeichen-Replacements als Hard-Block markiert. NGINX Plus über das offizielle Repo auf R36 P1 patchen (R32 P2 / R33 P3 / R34 P3 / R35 P2 / R36 P1 sind die aktuellen Patch-Linien je nach Plattform-Bestands-Stand). Access-Log-Audit auf das Exploit-Pattern über die letzten 7 Tage rückblickend, im Treffer-Fall mandantenscharfe Aufarbeitung der betroffenen Requests. WAF-Front-Edge-Regel als Default, nicht als Stopgap — die Pattern-Filter-Schicht gehört in eine Enterprise-Plattform als feste Komponente.

Kubernetes-Plattform

Wer NGINX als Ingress-Controller auf Kubernetes-Plattformen fährt (ingress-nginx, NGINX Ingress, Tekton-getriebene Plattformen), patcht den Ingress-Controller über den Helm-Chart-Pin auf die gepatchte Image-Linie. Helm-Chart-Pin auf ingress-nginx-v1.13.x oder neuer (NGINX Ingress 5.0+ entsprechend). Snippet-Annotationen (nginx.ingress.kubernetes.io/server-snippet, nginx.ingress.kubernetes.io/configuration-snippet) auf das Rewrite-Pattern prüfen — auch hier benannte Captures setzen statt $1. Falco-Rule für NGINX-Worker-SIGSEGV Cluster-weit ausrollen, damit Crash-Pattern im Verlauf des Wochenendes nicht übersehen werden.

• Sub-Szenario ingress-nginx mit Mandanten-spezifischen Snippets: Snippet-Audit pro Mandant, weil die Rewrite-Direktiven mandantenscharf konfiguriert sind und der Lint mandantenspezifische Treffer ausgibt.
• Sub-Szenario Service-Mesh mit NGINX-Sidecar: Wenn Istio/Linkerd mit NGINX-basiertem Egress-Sidecar arbeitet (selten, aber im DACH-Bestand vorhanden), Sidecar-Image auf gepatchte Linie heben.

Deklarative Stacks (NixOS / Talos / Flatcar / Wolfi)

NixOS-Module für nginx aktualisieren, sobald der nixpkgs-Bump für 1.30.1 gemerged ist (Stand 15.05.: PR ist in nixos-unstable gemerged, Channel-Sync läuft). Wolfi-basierte nginx-Pakete schließen den Patch über das apk-Index-Update der laufenden Woche — Image-Rebuild auf Wolfi-Base mit apk upgrade nginx, Helm-Chart-Pin auf das neue Image-Tag, Cluster-Rollout im Standard-Wartungsfenster. Self-hosted-Edge-Hosts auf Talos- oder Flatcar-Base übernehmen den Patch mit der Image-Promotion; deklarative Stacks haben den Vorteil, dass die Konfigurations-Vorlage gleichzeitig dem Lint unterworfen werden kann — der NixOS-Modul-Wrapper für services.nginx kann den benannten-Capture-Pattern direkt erzwingen.

Was wir konkret getan haben

Wir haben am 14.05.2026 zwischen 16:00 und 20:00 CEST und am 15.05.2026 zwischen 09:00 und 13:00 CEST vier Disziplinen durchgezogen.

Zuerst der Konfigurations-Lint: alle NGINX-Konfigurationen in den Mandanten-Plattformen über ein zentrales Audit-Skript gescannt. 23 NGINX-Hosts in 17 Mandanten-Plattformen, davon 19 Hosts mit rewrite-Direktiven in der aktiven Konfiguration. 14 Hosts hatten unbenannte Captures, 11 davon mit Fragezeichen im Replacement, 8 davon mit einer Folge-set- oder rewrite-Direktive. Acht direkt vulnerable Konfigurations-Stellen in fünf Mandanten-Plattformen — alle in TYPO3-Backend-Locking-Mustern oder Sylius-Multi-Channel-Routing.

Dann der Konfigurations-Pin auf benannte Captures: alle acht Stellen auf benannte Captures umgeschrieben ((?<path>.+) statt (.+) mit $1). Pull Requests vom Plattform-Team in Cohorts (2 Mandanten pro Cohort) gemerged, mit jeweils einem Smoke-Test gegen die Live-Mandanten-URL, der die Rewrite-Pfad-Konsistenz prüft. Bei einem Mandanten musste ein zweistufiges Migrations-Wartungsfenster eingeplant werden, weil das Sylius-Channel-Routing mehrere ineinander verschachtelte Rewrites enthielt und der Smoke-Test einen Pfad-Regression-Treffer ausgab — dort haben wir die Konfigurations-Änderung am 15.05. 12:00 CEST nachgezogen.

Dann der Patch-Rollout: alle 23 NGINX-Hosts auf nginx 1.30.1 über den Distro-Patch-Pfad gehoben. Die Hosts auf Debian-12-Basis (17 Hosts) hatten den Backport seit 13.05. abends im Sec-Updates-Stream verfügbar; die Hosts auf AlmaLinux-9-Basis (5 Hosts) bekamen den Backport aus dem Testing-Channel mit explizitem dnf install aus dem nginx:1.30-Modul; ein einzelner Host auf NGINX Plus R34 bekam das nginx-plus-r34-p3-Update aus dem offiziellen NGINX-Repo. Patch-Cohorts à drei Hosts mit 15-Minuten-Beobachtungsfenster, in dem die Mandanten-Plattform-Health-Checks parallel liefen.

Schließlich die Detection-Stage: Falco-Regel NGINX worker process killed by signal SEGV auf den 23 Hosts aktiviert. WAF-Regel-Pattern auf den Cloudflare-Edge-Hosts der drei Plattformen ergänzt, die hinter Cloudflare sitzen — als Default-Schicht, nicht als Stopgap. Access-Log-Audit auf das Exploit-Pattern über die letzten 7 Tage rückblickend gefahren — keine Treffer, das Pattern ist im Mandanten-Traffic nicht im Mass-Exploit-Modus aufgetreten. Detection-Pattern bleibt aktiv für die kommenden 30 Tage, weil PoC öffentlich ist und Mass-Exploit-Wellen typisch eine Woche nach Patch-Disclosure einsetzen.

Was wir nicht getan haben: einen NGINX-Service-Restart auf allen Hosts gleichzeitig. Der Service-Reload (systemctl reload nginx) zieht die offenen Verbindungen sauber zu Ende, während der Patch in den neuen Workern bereits aktiv ist. Ein Restart hätte die offenen Mandanten-Verbindungen abgebrochen, was im Tageszeit-Fenster auf einer Mandanten-Plattform mit Live-Traffic einen sichtbaren Service-Einbruch ergibt.

Die strukturelle Lehre aus diesem Vorgang sitzt nicht im Heap-Overflow, sondern im Verhältnis zwischen Sizing-Pfad und Write-Pfad in einer alten Codebase. NGINX hat 18 Jahre lang stabil funktioniert, weil die Diskrepanz zwischen ngx_escape_uri() und ngx_escape_html() im Sonderzeichen-Set nicht durch eine typische Konfigurations-Klasse scharf gestellt wurde. Die Lehre liegt in der Konfigurations-Disziplin. Benannte Captures sind keine reine Code-Style-Frage; sie sind eine Robustheits-Disziplin gegen genau diese Klasse von Befunden, die aus internen Funktions-Inkonsistenzen entstehen. Das ist die strukturelle Klasse, in der die Webserver-Schicht heute steht: nicht durch böswilligen Traffic kompromittiert, sondern durch alte Konsistenz-Annahmen, die in seltenen Konfigurations-Pfaden brechen. Wir haben in der laufenden Maiwoche genau dieses Pattern bei Apache mod_http2 (CVE-2026-23918 vom 13.05.) und jetzt bei NGINX Rift gesehen — beide HTTP-Server-Klassen sitzen in der gleichen strukturellen Schwäche.

Im weiteren Architektur-Bogen ist die Antwort kein einzelner Patch, sondern die Webserver-Konfigurations-Disziplin als eigene Plattform-Komponente. Patch auf die gepatchte Linie ist die Notfallmaßnahme; die strukturelle Antwort ist eine kuratierte NGINX-Konfigurations-Vorlage mit benannten Captures als Default, ein Pre-Receive-Hook gegen unbenannte Captures im zentralen Konfigurations-Repo, und ein vierteljährliches Konfigurations-Audit auf vergleichbare Konsistenz-Pfade. Drei Disziplinen, die nicht einzeln den NGINX-Rift verhindert hätten, aber zusammen den Wirkungsraum eines vergleichbaren Vorfalls auf wenige Konfigurations-Pfade statt 23 Hosts reduzieren.

Fazit

CVE-2026-42945 ist im Mai-Patch-Cycle eine strukturelle Lücke der schwersten Klasse: CVSS 9.2, unauthenticated, internet-exponiert, 18 Jahre alt, in der Mainline und in NGINX Plus parallel, mit öffentlichem PoC seit 14.05. Was den Befund operativ erträglich macht, ist die schnelle Patch-Verfügbarkeit (13.05. ab 07:00 UTC) und die klare Trigger-Bedingung (unbenannte Capture + Fragezeichen + Folge-Direktive), die sich konfigurations-seitig adressieren lässt.

Die Frage lautet nicht, ob nginx 1.30.1 ausreicht. Die Patch-Linie reicht für den konkreten Pfad, den NGINX am 13. Mai geschlossen hat. Sie lautet, ob Ihre Plattform die Webserver-Konfigurations-Disziplin als eigene Komponente führt, oder ob NGINX-Konfigurationen weiterhin als „Plattform-Detail“ durch die Mandanten-Wartung wandern. Die strukturelle Antwort ist die erste Variante, mit kuratierten Konfigurations-Vorlagen, benannten Captures als Default, Pre-Receive-Hook gegen das fragile Pattern, vierteljährlichem Konfigurations-Audit auf vergleichbare Konsistenz-Pfade.

Persönlicher Hintergrund und technische Details zur Webserver-Disziplin im DACH-Mittelstand: ole-hartwig.eu.