Kritische nginx-Lücke CVE-2026-42945: Version prüfen, patchen und absichern

Am 13. Mai 2026 hat das nginx-Projekt ein Sicherheits-Advisory zu CVE-2026-42945 veröffentlicht – einem Heap-Buffer-Overflow im ngx_http_rewrite_module mit einem CVSS-v4.0-Score von 9.2. Der Fehler steckt seit Version 0.6.27 (2008) im Code; ein unauthentifizierter Angreifer kann mit einer einzelnen manipulierten HTTP-Anfrage einen Absturz des Worker-Prozesses auslösen und unter bestimmten Bedingungen (deaktiviertes ASLR) Code ausführen. Betroffen ist praktisch jede nginx-Installation von 0.6.27 bis 1.30.0. Dieser Beitrag zeigt den nüchternen Arbeitsablauf: Version feststellen, gegen die betroffenen Releases abgleichen, patchen, verifizieren.

Wer ist betroffen – und was ist gefixt

Laut dem offiziellen nginx-Security-Advisory gilt:

• Verwundbar: nginx 0.6.27 bis einschließlich 1.30.0
• Nicht mehr verwundbar: 1.30.1 (Stable-Branch) und 1.31.0 (Mainline-Branch) sowie neuere

Der Fehler wird nur schlagend, wenn Ihre Konfiguration ein rewrite-Muster mit unbenannter PCRE-Capture ($1, $2 …) und einem Fragezeichen im Ersetzungsstring nutzt. Solche Muster sind in der Praxis alltäglich – etwa beim Umschreiben von Query-Strings oder beim Anhängen von Parametern. Verlassen Sie sich aber gar nicht erst darauf, dass Ihre Konfiguration „schon nicht betroffen“ sei: Die Analyse einer Live-Konfiguration ist fehleranfällig, und bei einem CVSS-Score von 9.2 ist das schlichte Anheben auf eine gefixte Version ungleich verlässlicher als jede Ausnahmeprüfung. Prüfen Sie deshalb zuerst, welche Version überhaupt läuft, und patchen Sie dann unabhängig davon, ob Sie das auslösende Muster in Ihrer Konfiguration vermuten oder nicht.

Wichtig zur Einordnung: Es existiert öffentlicher Proof-of-Concept-Code, und die Lücke wird bereits aktiv ausgenutzt. VulnCheck beobachtete ab dem 16. Mai 2026 – nur drei Tage nach Veröffentlichung von Advisory und PoC – Ausnutzungsversuche gegen seine Canary-Systeme. Das erhöht die Dringlichkeit zusätzlich: Bei einem unauthentifizierten Overflow ohne Vorbedingungen zählt jeder Tag.

Schritt 1: Installierte Version feststellen

Auf dem Host:

nginx -v
# nginx version: nginx/1.30.0

In einem Container laufen oft andere Versionen als auf dem Host. Prüfen Sie jeden nginx-Container einzeln:

# alle laufenden Container auflisten
docker ps --format '{{.Names}}\t{{.Image}}'

# Version im konkreten Container abfragen
docker exec <CONTAINER_NAME> nginx -v

nginx -v schreibt die Versionsausgabe nach stderr, nicht stdout – bei einer Weiterleitung in eine Datei müssen Sie also 2>&1 anhängen.

Schritt 2: Gegen die betroffenen Versionen abgleichen

Der Vergleich ist simpel: Alles bis 1.30.0 ist betroffen. Nur 1.30.1 / 1.31.0 und höher sind sauber.

+----------------------+---------------------+
| gemeldete Version    | Bewertung           |
+----------------------+---------------------+
| 0.6.27 ... 1.30.0    | BETROFFEN -> patchen|
| 1.30.1 (stable)      | OK                  |
| 1.31.0 (mainline)    | OK                  |
| >= 1.31.1            | OK                  |
+----------------------+---------------------+

Schritt 3: Patchen

Variante A: Docker-Image auf ein gefixtes Tag heben

Die offiziellen nginx-Docker-Images folgen zwei Linien: nginx:stable (Stable-Branch) und nginx:mainline bzw. nginx:latest (Mainline). Pinnen Sie in Produktion auf eine konkrete gefixte Version statt auf ein wanderndes Tag:

# vorher (verwundbar)
FROM nginx:1.30.0

# nachher (gefixt, Stable-Branch)
FROM nginx:1.30.1

Im Compose-Stack analog:

services:
  web:
    image: nginx:1.30.1
    restart: unless-stopped

Neu ziehen und ausrollen:

docker compose pull
docker compose up -d

Variante B: Distro-Paket aktualisieren

Nutzen Sie das nginx aus den Paketquellen der Distribution, aktualisieren Sie über den Paketmanager. Der Patch wandert je nach Distribution als Backport in die vorhandene Versionsnummer – die „Distro-Version“ kann also weiter 1.30.0 anzeigen, obwohl der Fix eingespielt ist (siehe Stolperfalle 2).

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
sudo systemctl restart nginx

# RHEL/Alma/Rocky
sudo dnf upgrade nginx
sudo systemctl restart nginx

Schritt 4: Verifizieren

Nach dem Ausrollen erneut die Version abfragen – auf dem Host und in jedem Container:

nginx -v
docker exec <CONTAINER_NAME> nginx -v
# erwartet: nginx/1.30.1 (oder hoeher)

Bei einem Distro-Backport, wo die Versionsnummer gleich bleibt, prüfen Sie stattdessen das Changelog des Pakets:

# Debian/Ubuntu: enthaelt der Changelog die CVE?
zcat /usr/share/doc/nginx/changelog.Debian.gz | grep -i 42945

Zum Schluss: Läuft der Dienst wieder sauber und antwortet er?

docker compose ps
curl -sI http://localhost/ | head -n 1
# HTTP/1.1 200 OK

Drei typische Stolperfallen

1. Eingebettetes nginx nicht vergessen. nginx steckt nicht nur in Ihrem Reverse Proxy. Viele Images bringen ein eigenes nginx mit – etwa Frontend-Container, nginx:*-basierte Basis-Images, das nginx Ingress im Kubernetes-Cluster oder Appliance-Images. Gehen Sie mit docker ps und docker exec ... nginx -v wirklich jeden Container durch, nicht nur den offensichtlichen Proxy.

2. nginx -v zeigt nicht immer den Patchlevel. Distributionen backporten Sicherheitsfixes oft in die bestehende Versionsnummer. Ein 1.30.0 aus den Debian-Quellen kann längst gepatcht sein, während dasselbe 1.30.0 als offizielles Upstream-Binary verwundbar ist. Verlassen Sie sich bei Distro-Paketen auf das Changelog, nicht allein auf die Versionszeile.

3. stable und mainline verwechseln. Die Docker-Tags nginx:stable und nginx:mainline zeigen auf unterschiedliche Branches. Der Fix liegt in beiden (1.30.1 bzw. 1.31.0). Pinnen Sie in Produktion auf eine exakte Version und ziehen Sie nicht blind latest – sonst wandert das Tag beim nächsten Release unkontrolliert weiter.

Wie es weitergeht

Behandeln Sie das Update als das, was es bei CVSS 9.2 ist: dringend. Für die Details lohnt der Blick in die offizielle Advisory-Übersicht, die Dokumentation zum Rewrite-Modul und die Changelog-Seite von nginx, auf der Sie den genauen Fix je Release nachlesen können.