NGINX: drei kritische Lücken, Update auf 1.30.6 / 1.31.7

Ein Sysadmin schläft nie ganz. Kaum ist PHP gepatcht, meldet F5 drei kritische Lücken in NGINX Open Source und NGINX Plus, jede mit CVSS 9.2. Möglich sind Abstürze einzelner Worker (DoS) und unter Umständen Codeausführung. Die gute Nachricht: Anders als bei PHP2Shell ist nicht jede Installation automatisch angreifbar. Es kommt auf bestimmte Direktiven an. Die schlechte: Eine offizielle Zwischenlösung gibt es nicht, nur das Update.

Die drei Lücken in einem Satz

CVE-2026-15176: Heap-Überlauf, wenn alias mit rewrite und einem set oder return zusammenkommt, das $request_filename verwendet. Auch $request_filename im Access-Log-Format reicht.
CVE-2026-97205: Use-after-free, wenn asynchrones Datei-I/O (aio) aktiv ist und SSI-Seiten mit virtuellen Includes verarbeitet werden.
CVE-2026-93479: Heap-Überlauf bei regulären Ausdrücken in map, wenn root oder ein Log-Format Capture-Variablen vor der Map-Ausgabe verwendet.

Alle drei betreffen nur die Datenebene. Für Codeausführung muss zusätzlich ASLR umgangen werden. Aktive Angriffe sind derzeit nicht bekannt.

Welche Versionen?

NGINX Open Source ist in 1.31.7 und 1.30.6 repariert. NGINX Plus in 37.1.0.1 und 37.0.5.1; für R33 bis R36 gibt es keinen Fix im selben Zweig, dort hilft nur der Umstieg. Ältere Versionen sind teilweise ebenfalls betroffen, bis zurück zu sehr alten Releases.

In fünf Minuten prüfen

nginx -v
nginx -T 2>/dev/null | grep -nE 'request_filename|^\s*aio\s|^\s*ssi\s+on'
nginx -T 2>/dev/null | grep -nE '^\s*map\s'
for c in $(docker ps --format '{{.Names}}'); do docker exec $c nginx -v 2>/dev/null && echo "  ^ $c"; done

Die erste Zeile zeigt die Version. Die zweite sucht die Direktiven der ersten beiden Lücken in der kompletten, aufgelösten Konfiguration (auch in eingebundenen Dateien). Die dritte listet alle map-Blöcke: Dort genau hinschauen, ob reguläre Ausdrücke mit Capture-Gruppen verwendet werden und ob diese Captures in root oder einem log_format auftauchen. Die letzte Zeile findet NGINX in Containern, die man gerne vergisst.

Patchen, je nachdem woher NGINX kommt

Distribution: apt update && apt upgrade und im Changelog des Pakets nach den CVE-Nummern suchen. Distributionen liefern den Fix oft unter alter Versionsnummer.
Panel (Plesk, cPanel): Das Panel bringt sein eigenes NGINX mit. Nicht von Hand ersetzen, sondern das Update des Herstellers abwarten und automatische Updates eingeschaltet lassen. Bis dahin die Konfiguration prüfen.
Container: Image auf nginx:1.30.6-alpine oder neuer heben. Wer die App nicht neu bauen will, tauscht nur die Laufzeit-Schicht: neues NGINX-Image als Basis, fertige Dateien und Templates aus dem alten Image kopieren, Container neu starten.

Danach nginx -t und ein Reload. Bei Containern den Container neu erstellen, nicht nur neu starten.

Wie es bei mir aussah

Das NGINX vor meinen Websites kommt vom Panel und war auf 1.30.5. Ein gepatchtes Paket gab es dort noch nicht. Die Prüfung der kompletten Konfiguration zeigte: kein $request_filename, kein aio, kein SSI, und die map-Blöcke nutzen keine Captures. Also nicht angreifbar, und das Update kommt automatisch, sobald der Hersteller es liefert. Ein Container mit eigenem NGINX lief noch auf 1.29.8. Den habe ich sofort auf 1.30.6 gehoben, ohne die App neu zu bauen.

Ein paar Ratschläge

Kein Grund zur Panik, aber auch keiner zum Liegenlassen. Die Konfiguration kann sich mit dem nächsten Deployment ändern. Was heute nicht angreifbar ist, kann es morgen sein.
Die aufgelöste Konfiguration prüfen (nginx -T), nicht nur die eigene Datei. Viele Direktiven kommen aus Includes von Panel oder Paketen.
Container nicht vergessen: Frontends, Admin-Oberflächen und Office-Dienste bringen oft ihr eigenes NGINX mit.
Bewegliche Tags meiden: FROM nginx:alpine ist bequem, aber man weiß nie, welche Version gerade läuft. Lieber eine konkrete Version festschreiben und bewusst anheben.
Eine kleine Inventarliste führen: Wo läuft NGINX, wo PHP, wo welches Image. Nach PHP2Shell vor zwei Tagen hat sie sich bei mir schon zweimal ausgezahlt.

Quellen: NGINX Security Advisories und Cyber Security Agency of Singapore. Zum Vergleich: mein Beitrag zum PHP-Notfall-Update.