Security 15.10.2026, 22:28 Aktualisiert: 15.10.2026, 22:28

NGINX: CVE-2026-97205, CVE-2026-93479 und CVE-2026-15176 patchen

Drei NGINX-Lücken in AIO/SSI, map und alias: Angriffsvoraussetzungen, technische Ursachen, Patchstände der Distributionen und sichere Updatepfade.

Von Moritz Mantel · Veröffentlicht: 15.10.2026, 22:28 · Aktualisiert: 15.10.2026, 22:28

Stand: 15.10.2026, 22:28 Uhr CEST. NGINX hat am 14. Oktober die Versionen 1.30.6 stable und 1.31.7 mainline veröffentlicht. Sie schließen unter anderem drei Speicherfehler in AIO/SSI, der Variablenauswertung und der Kombination aus alias und rewrite. Für Distributionspakete ist die Lage noch uneinheitlich: Debian Sid hat einen Backport, Bookworm und Trixie stehen im Tracker noch auf „vulnerable“. Bestätigte Fixstände und noch ungeklärte Vendor-Stände sind unten getrennt aufgeführt.

Kurzfassung

Remote angreifbar: Ja, ohne Anmeldung, wenn die jeweils erforderliche Konfiguration und ein ungepatchter Build zusammenkommen. Ein lokaler Shell-Zugang ist nicht nötig.
CVE-2026-97205: Use-after-free bei asynchronem Datei-I/O und SSI-Seiten mit include virtual. Ohne den betroffenen AIO-/SSI-Pfad greift dieser beschriebene Angriff nicht.
CVE-2026-93479: Heap-Buffer-Overflow beim Auswerten von Variablen. Relevant sind unter anderem Regex-Captures aus map, die in root oder einem Access-Log-Format vor der zugehörigen Map-Ausgabe verwendet werden. Auch nicht cachebare Variablen können den Fehler auslösen.
CVE-2026-15176: Heap-Buffer-Overflow, wenn NGINX nach einem rewrite innerhalb einer alias-Location einen Dateipfad berechnet, etwa für $request_filename.
Auswirkung: Worker können abstürzen. Codeausführung ist laut F5 bei ausgeschalteter oder umgangener ASLR möglich. Daraus folgt keine pauschale Root-Lücke für jeden NGINX-Server.
Fix: NGINX Open Source 1.30.6 oder 1.31.7, ein bestätigter Distributions-Backport oder der passende NGINX-Plus-Fix. Alte Fixstände aus den HTTP/2-/HTTP/3-Lücken vom Juni reichen hierfür nicht.
Zuerst prüfen: Paketquelle, vollständige Paketversion und die Konfiguration der tatsächlich laufenden Instanz. Nach dem Binary-Update muss NGINX den neuen Programmcode ausführen. Ein gewöhnlicher Reload allein ersetzt die Binary nicht.

Was wurde veröffentlicht?

Die Ausgangsmeldung bei Cyber Security News behandelt drei am 14. Oktober veröffentlichte F5-Advisories. Alle drei betreffen die Verarbeitung von Nutzerverkehr im NGINX-Worker. Ein Zugriff auf eine Verwaltungsoberfläche ist dafür nicht erforderlich.

F5 bewertet die CVEs jeweils mit CVSS 3.1 8,1 und CVSS 4.0 9,2. Die NGINX-Projektübersicht verwendet dagegen die Einstufung „medium“. Das sind unterschiedliche Bewertungssysteme. Für die Priorisierung zählt, ob ein erreichbarer vHost den betroffenen Codepfad nutzt. Die Herstellerbeschreibungen stehen in den F5-CVE-Datensätzen zu 97205, 93479 und 15176; die Versionsgrenzen nennt die NGINX-Sicherheitsübersicht.

Dieselben Releases schließen außerdem CVE-2026-95101 bei der HTTP/3-Request-Body-Verarbeitung und CVE-2026-97629 bei der Rotation von TLS-Session-Ticket-Schlüsseln. Die drei hier beschriebenen Konfigurationsmaßnahmen decken diese beiden zusätzlichen Fehler nicht ab. Wer ohnehin aktualisiert, sollte den vollständigen Fixstand einspielen. Quelle: NGINX-Changelog für 1.30.6.

Wie funktionieren die drei Lücken?

CVE-2026-97205: Ein Zähler läuft über, während Dateioperationen noch arbeiten

SSI setzt eine Antwort auf dem Server aus mehreren Bestandteilen zusammen. Ein include virtual kann dafür einen weiteren internen Request starten. AIO erlaubt NGINX, Dateioperationen asynchron zu bearbeiten, während der Worker andere Aufgaben übernimmt. Die Grundfunktionen beschreibt die SSI-Dokumentation.

Der Fehler liegt in der Verwaltung noch ausstehender Operationen. NGINX zählt sie in r->main->blocked, einem 8-Bit-Feld. Vor dem Fix fehlte eine Überlaufprüfung. Bei 256 gleichzeitig ausstehenden Operationen konnte der Zähler wieder auf null springen. Der Request sah damit so aus, als würde keine Operation mehr auf ihn warten. Sein Speicher konnte freigegeben werden, obwohl laufende Operationen noch darauf verwiesen.

Greift eine solche Operation später auf den freigegebenen Request-Speicher zu, entsteht der Use-after-free. Der Upstream-Fix begrenzt die Zahl ausstehender Operationen. Überzählige Operationen laufen synchron, soweit es dafür einen Pfad gibt, oder werden abgewiesen.

Für den Betrieb heißt das: AIO allein ist noch kein Nachweis der beschriebenen Angriffssituation. Prüfe, ob SSI aktiv ist und erreichbare Antworten tatsächlich include virtual verwenden. Solche Inhalte können auch aus einem Backend kommen. Nur nach .shtml-Dateien im Document Root zu suchen, reicht deshalb nicht. Die Verbindung aus AIO und SSI nennt F5 im Advisory K000162608.

CVE-2026-93479: Variablen verändern die Länge eines Strings

Eine map wird erst ausgewertet, wenn ihr Ergebnis gebraucht wird. Enthält sie einen Regex, kann dieser beim Auswerten die positionalen Captures $1 bis $9 ersetzen. Steht in einem Ausdruck zuerst ein Capture und erst danach die Map-Ausgabe, kann die spätere Auswertung den zuvor verwendeten Wert verändern. Dieses Verhalten erläutert die NGINX-Dokumentation zu map.

NGINX muss für solche Ausdrücke zunächst Speicher einplanen und anschließend den String zusammensetzen. Der Oktober-Fix betrifft dabei einen zusätzlichen reservierten Bereich des Puffers: Vorhandene Schutzprüfungen verhinderten nicht vollständig, dass Stringdaten in diesen Bereich gerieten. Durch eine spätere Neuberechnung konnte die resultierende Länge größer als der tatsächlich reservierte Gesamtpuffer werden. Nachfolgender Code konnte dann über dessen Ende schreiben.

Der Patch zur Script-Auswertung nennt die Berechnung des Document Roots sowie Access-Logging in HTTP und Stream. Für den Logging-Pfad beschreibt der Commit die mögliche Überschreibung als einzelnes Nullbyte. Das sollte man nicht mit einem beliebig großen Schreibzugriff in jedem Log-Setup gleichsetzen.

Ein verdächtiges Muster ist somit root oder log_format mit Captures vor einer Map-Variablen, deren Auswertung diese Captures beeinflusst. Daneben nennt F5 K000162607 nicht cachebare Variablen in Stringausdrücken als weiteren Pfad. Ein leeres Suchergebnis für $1 ist deshalb keine vollständige Entwarnung.

CVE-2026-15176: Neue URI, aber noch die alte alias-Location

alias ordnet einen Location-Präfix einem Verzeichnis zu. Nach einem rewrite kann die URI bereits geändert sein, während NGINX noch die übrigen Rewrite-Anweisungen der bisherigen Location abarbeitet. Genau in diesem Zwischenzustand kann die Pfadberechnung schiefgehen.

Ist der alte Location-Präfix länger als die neue URI und wird jetzt ein Dateipfad berechnet, kann ein Buffer-Overflow entstehen. Der Upstream-Patch verweigert diese Zuordnung, solange die URI als geändert markiert ist und die Location-Zuordnung noch nicht passt.

$request_filename löst eine solche Pfadberechnung aus. Prüfe die Variable deshalb nicht nur in set und return, sondern auch in log_format, if oder add_header. Diese weiteren Verwendungen nennt die Patchbeschreibung ausdrücklich. Das erklärt, warum eine scheinbar harmlose zusätzliche Log-Spalte den betroffenen Pfad erreichen kann.

Es geht hier um Speicherbeschädigung im Worker. Die bekannte Frage nach einem fehlenden Slash in einer alias-Konfiguration ist eine andere Baustelle. Für diese CVE zählt die Kombination aus URI-Umschreibung und anschließender Pfadberechnung. Die Herstellerbeschreibung steht in F5 K000162416.

Welche Versionen sind betroffen?

Die folgende Tabelle gilt für die unveränderten Upstream-Versionen. Distributions-Backports müssen separat bewertet werden.

CVE	Verwundbare Upstream-Versionen laut NGINX	Gefixte gepflegte Zweige
CVE-2026-97205	`0.8.11` bis `1.31.6`, ausgenommen bereits gefixte Stable-Releases	`1.30.6+` stable, `1.31.7+` mainline
CVE-2026-93479	`1.30.0` bis `1.30.5` sowie `1.31.2` bis `1.31.6`	`1.30.6+` stable, `1.31.7+` mainline
CVE-2026-15176	`0.1.29` bis `1.31.6`, ausgenommen bereits gefixte Stable-Releases	`1.30.6+` stable, `1.31.7+` mainline

Quelle: NGINX Security Advisories. Das Pluszeichen steht jeweils für spätere Versionen desselben gepflegten Zweigs.

Für NGINX Plus nennen die F5-CVE-Datensätze als Fixgrenzen 37.0.5.1 beziehungsweise 37.1.0.1. Damit reicht 37.0.5 oder 37.1.0 noch nicht. Auch R33 bis R36 werden als betroffen aufgeführt; dafür ist anhand des F5-Advisories der unterstützte Upgradepfad zu wählen. Eingebettete NGINX-Versionen in Ingress-Controllern, Gateways oder WAF-Produkten brauchen den Fix ihres jeweiligen Produkts.

Was ist nicht betroffen oder vorübergehend entschärft?

Ein Build mit nachgewiesenem Fix für die jeweilige CVE ist nicht mehr betroffen. Bei CVE-2026-93479 liegen unveränderte ältere Upstream-Versionen außerhalb des angegebenen Versionsbereichs. Das lässt sich wegen möglicher Backports nicht blind auf ein Distributionspaket übertragen.

Eine Konfiguration ohne den jeweiligen Auslöser verhindert den beschriebenen Angriffspfad, macht aber aus einem ungepatchten Paket kein gepatchtes. Insbesondere schützt das Abschalten von SSI nicht vor den beiden anderen CVEs. ASLR ist ebenfalls kein Fix: Sie erschwert mögliche Codeausführung, verhindert aber die zugrunde liegende Speicherbeschädigung nicht.

Patchstände nach Distribution

Alle Angaben sind eine Momentaufnahme zum Stand oben. „Nicht bestätigt“ bedeutet, dass wir keinen belastbaren Fixstand verifizieren konnten. Es bedeutet weder „nicht betroffen“ noch „der Hersteller hat garantiert noch kein Update“. Testing-Pakete sind außerdem getrennt von regulär ausgelieferten Updates aufgeführt.

Debian und Ubuntu

Distribution / Release	CVE-2026-97205	CVE-2026-93479	CVE-2026-15176
Debian 12 Bookworm	`vulnerable`, auch Security-Paket `1.22.1-9+deb12u10`	`vulnerable`, gleicher Stand	`vulnerable`, gleicher Stand
Debian 13 Trixie	`vulnerable`, auch Security-Paket `1.26.3-3+deb13u9`	`vulnerable`, gleicher Stand	`vulnerable`, gleicher Stand
Debian Forky	`1.30.4-7` noch `vulnerable`	`1.30.4-7` noch `vulnerable`	`1.30.4-7` noch `vulnerable`
Debian Sid	Gefixt ab `1.30.4-8`	Gefixt ab `1.30.4-8`	Gefixt ab `1.30.4-8`
Ubuntu 26.04, 24.04 und 22.04 LTS	Kein Fixstand bestätigt; CVE-Seite beim Abruf nicht verfügbar	Kein Fixstand bestätigt; CVE-Seite beim Abruf nicht verfügbar	`Needs evaluation`, noch keine Fixversion genannt
Ubuntu 20.04, 18.04 und ältere Pro-/ESM-Pfade	Kein Fixstand bestätigt	Kein Fixstand bestätigt	Die geprüfte Ubuntu-Seite führt auch 20.04, 18.04, 16.04 und 14.04 als `Needs evaluation`

Quellen: Debian-Tracker für 97205, 93479 und 15176 sowie Ubuntu für CVE-2026-15176.

Bei CVE-2026-93479 fällt ein Unterschied auf: NGINX nennt einen engen Upstream-Bereich, Debian markiert trotzdem ältere Bookworm- und Trixie-Pakete als verwundbar. Aus den geprüften Trackereinträgen allein lässt sich die Ursache dieses Unterschieds nicht sicher ableiten. Für die Betriebsentscheidung bleibt der produktspezifische Debian-Status maßgeblich. Eine Entwarnung nur wegen nginx/1.22.1 wäre hier nicht belastbar.

Für Debian 11 beziehungsweise externe ELTS-Angebote ist kein Fixstand bestätigt. Ein Sid-Paket ist auch kein Updatevorschlag für einen produktiven Bookworm-Server: Nutze den passenden Security-Kanal und entschärfe bis zum bestätigten Backport die betroffene Konfiguration.

Weitere Linux-Distributionen

Distribution / Paketkanal	Verifizierter Stand und Konsequenz
RHEL 8/9/10, AppStreams und EUS	Kein Fixpaket für die drei CVEs bestätigt. Die Red-Hat-Daten waren beim Abruf nicht auswertbar. Stream und Produktvariante gegen die Red-Hat-Sicherheitsdaten prüfen; keine pauschale Einstufung als gefixt oder nicht betroffen.
AlmaLinux 8/9/10	Kein eigener ALSA-Fixstand bestätigt. Ein RHEL- oder fremdes RPM ist kein Nachweis für das aktivierte Alma-Repository. Maßgeblich sind die AlmaLinux-Errata und die vollständige RPM-Version.
Rocky Linux 8/9/10	Kein eigener RLSA-Fixstand bestätigt. Den konkreten NGINX-Stream anhand der Rocky-Errata und Repository-Metadaten prüfen.
Oracle Linux 8/9/10	Kein ELSA-Fixstand bestätigt; die drei CVE-Seiten waren beim Abruf nicht verfügbar. Den eigenen Kanal über Oracle Linux Security prüfen.
SUSE Linux Enterprise / openSUSE Leap	Für 97205 und 93479: `Pending`, betroffene Produkte unter anderem SLES 15 SP7, SLES 16.0 und Leap 16.0; noch kein Security-Advisory mit Fixpaket verknüpft. Für 15176 war die CVE-Seite nicht verfügbar. Quellen: SUSE für 97205 und 93479.
openSUSE Tumbleweed	Kein eigener Paket-Fixstand bestätigt. Den SLE-/Leap-Status nicht auf Tumbleweed übertragen; Paket-Changelog oder Upstream-Fixversion nachweisen.
Fedora 43/44	Die Fedora-Paketübersicht zeigt regulär `1.30.5-1.fc43` beziehungsweise `1.30.5-1.fc44`, ohne Testing-Fix. Damit ist dort noch kein Oktober-Fix bestätigt.
Fedora 45 / Rawhide	Fedora 45 führt `1.30.6-2.fc45` in Testing, regulär noch `1.30.5-2.fc45`. Rawhide zeigt `1.30.4-4.fc46`. Ein Testing-Build für Fedora 45 ist kein reguläres Update für Fedora 43/44. Quelle: dieselbe Fedora-Paketübersicht.
Alpine 3.21/3.22/3.23/3.24 und edge	In den geprüften `main`-Security-Daten ist noch kein Fix für diese drei CVEs eingetragen. Die Paketübersicht zeigt für 3.24 `1.30.4-r1` und für edge `1.30.4-r3`. Diese Angaben sind kein Oktober-Fixnachweis; Quelle zusätzlich: Alpine Security Database.
Arch Linux	`nginx-mainline 1.31.7-1` enthält den Upstream-Fix. Das getrennte Paket `nginx` steht noch auf `1.30.5-1` und ist als veraltet markiert. Quellen: nginx-mainline und nginx.
Gentoo	`www-servers/nginx-1.30.6` und `1.31.7` sind im Paketbaum vorhanden. Architektur-Keywords und die tatsächlich installierte Version prüfen. Quelle: Gentoo-Paketübersicht.
Amazon Linux 2 / 2023	Kein ALAS-Fixstand bestätigt; die drei CVE-Seiten waren beim Abruf nicht verfügbar. AL2-Extras und AL2023 über das jeweilige ALAS-Verzeichnis prüfen.
CloudLinux	Kein eigener Fixstand bestätigt. Ermitteln, ob NGINX aus dem OS-, Panel- oder einem anderen Paketkanal stammt; CloudLinux-Mitteilungen und dessen Paket-Changelog prüfen. Ein Kernel-Livepatch ersetzt kein NGINX-Update.

Wo ein Vendor-Backport noch nicht bestätigt ist, prüfst du die Konfiguration, entschärfst erreichbare Angriffspfade und gleichst den Paketkanal erneut gegen alle drei CVEs ab.

Plesk, cPanel und Container

Bei Plesk musst du insbesondere sw-nginx und die tatsächlich gestartete Binary prüfen. Das geprüfte Plesk-Changelog nennt zuletzt ein NGINX-Update auf 1.30.5; das ist noch nicht die Upstream-Fixversion für diese Oktober-Lücken. Ein passender Panel-Backport ist hier nicht bestätigt.

Bei cPanel/EasyApache kann ea-nginx maßgeblich sein. Auch dafür ist kein Oktober-Fixstand bestätigt; die ea-nginx-Release-Notes waren beim Abruf nicht auswertbar. Verlasse dich bei beiden Panels nicht darauf, dass ein aktuelles OS-Paket auch die panelverwaltete Instanz ersetzt.

Bei Containern liegt die NGINX-Binary im Image. Anders als bei Dirty Frag schließt ein Host-Kernel-Update diese Lücken nicht. Entscheidend sind Image-Inhalt und laufender Container. Auch ein Tag wie stable oder mainline beweist nicht, dass ein bereits gestarteter Pod die neue Version nutzt. Nach dem Image-Update müssen die Workloads ersetzt und kontrolliert werden.

Schnelle Prüfung auf einem Host

Die folgenden Kommandos sind Beispiele für Linux-Systeme. Sie führen keinen Exploit aus. Bei eigenen Service-Namen, Binary-Pfaden oder Startparametern musst du sie anpassen.

Zuerst Version, Build und Service-Zuordnung erfassen:

command -v nginx
nginx -v
nginx -V 2>&1
systemctl show nginx -p MainPID -p ExecStart -p FragmentPath
ps -eo pid,ppid,lstart,args | grep '[n]ginx'

nginx -v startet die Binary, die deine Shell findet. Das ist noch kein Beweis für die Version des laufenden Masters. Dessen Pfad kannst du bei einem üblichen systemd-Service so prüfen:

nginx_master_pid=$(systemctl show nginx -p MainPID --value)
if [ "${nginx_master_pid:-0}" -gt 0 ]; then
  sudo readlink "/proc/$nginx_master_pid/exe"
fi

Ein angehängtes (deleted) ist ein deutlicher Hinweis auf eine noch laufende, inzwischen ersetzte Datei. Kein solcher Hinweis ist umgekehrt kein vollständiger Fixnachweis. Vergleiche Paketstand, Binary-Pfad und den dokumentierten Neustart beziehungsweise Binary-Wechsel.

Auf Debian, Ubuntu und entsprechenden Panel-Hosts:

dpkg-query -W -f='${binary:Package}\t${Version}\n' 'nginx*' 'sw-nginx*'
apt-cache policy nginx nginx-core nginx-full nginx-extras sw-nginx

Auf RHEL, Alma, Rocky, Oracle, CloudLinux, Fedora oder Amazon Linux:

rpm -q nginx nginx-core sw-nginx ea-nginx
dnf info --installed nginx nginx-core sw-nginx ea-nginx
dnf updateinfo info --cves=CVE-2026-97205,CVE-2026-93479,CVE-2026-15176

Nicht installierte Paketnamen dürfen hier als fehlend gemeldet werden. Auf älteren Systemen ist gegebenenfalls yum statt dnf zu verwenden. Auch eine leere Updateinfo-Ausgabe ist keine Entwarnung: Repository, Subscription, Modulstream und Metadaten müssen zur Installation passen.

Für weitere Distributionen:

# SUSE / openSUSE
zypper se -si 'nginx*'

# Alpine
apk info -v nginx
apk policy nginx

# Arch Linux
pacman -Q nginx nginx-mainline

# Gentoo: installierte Version und vorgesehener Updatepfad
emerge --info www-servers/nginx
emerge --pretend --verbose --update www-servers/nginx

Konfiguration: Was muss tatsächlich zusammenkommen?

nginx -T liest und prüft die Konfiguration auf der Platte einschließlich Includes. Es ist kein Speicherauszug der bereits laufenden Konfiguration. Nutzt der Service -c oder -p, verwende dieselben Parameter. Noch nicht übernommene Dateiänderungen musst du vom Zustand des laufenden Prozesses unterscheiden. Die Ausgabe kann interne Adressen oder Zugangsdaten enthalten und sollte nicht ungeprüft weitergegeben werden.

sudo nginx -T

Als Suchhilfe in derselben Konfiguration:

sudo nginx -T | grep -nE \
  '(^|[[:space:]])(aio|ssi|map|root|alias|rewrite|set|return|if|add_header|log_format|access_log|volatile)([[:space:]]|;)|\$request_filename|\$[1-9]'

Die Treffer sind Einstiegspunkte. Lies anschließend die vollständigen Blöcke und die verwendeten Variablen:

CVE	Was zusammen geprüft werden muss
97205	AIO-Einstellung, aktive SSI-Verarbeitung und tatsächlich ausgelieferte Inhalte mit `include virtual`; auch Backend-Antworten berücksichtigen.
93479	Regex-Maps, Reihenfolge von Captures und Map-Ausgabe in Stringausdrücken, nicht cachebare Variablen sowie `root` und die verwendeten HTTP-/Stream-Logformate.
15176	`alias`-Location, URI-Änderung durch `rewrite` und anschließende Pfadberechnung über `$request_filename`, auch in Logging oder Headern.

Ein log_format kann weit entfernt von der betroffenen Location definiert sein. Bei Panels und Ingress-Controllern zählen außerdem die generierten Includes. Ein einzelner Treffer für alias oder map beweist noch keine Ausnutzbarkeit.

Mitigation, solange der passende Fix fehlt

Für CVE-2026-97205 nennt F5 das Abschalten von AIO oder das Vermeiden von SSI-Seiten. Als Konfigurationsoptionen kommen im tatsächlich betroffenen Kontext infrage:

# Möglichkeit 1: asynchrones Datei-I/O abschalten
aio off;

# Möglichkeit 2: SSI-Verarbeitung abschalten
ssi off;

Du musst nicht zwangsläufig beides abschalten. Prüfe aber Vererbung und spezifischere Locations. Ohne AIO kann sich das Verhalten bei großen Dateien und hoher Last ändern; ohne SSI fehlen möglicherweise zusammengesetzte Seitenbestandteile. Die Anwendung nach der Änderung mitprüfen.

Für CVE-2026-93479 empfiehlt F5 benannte statt unbenannter Captures und eine auf den Block mit dem Regex-Match begrenzte Nutzung. Das heißt mehr als $1 in $name umzubenennen: Der Ausdruck darf nicht weiterhin von einer späteren Map-Auswertung oder einem wechselnden Variablenwert abhängen. Wegen des zusätzlich beschriebenen Pfads über nicht cachebare Variablen bleibt der Fix die verlässlichere Lösung.

Für CVE-2026-15176 empfiehlt F5, alias in der betroffenen Location beziehungsweise $request_filename zu vermeiden. Ein Umbau auf root braucht einen Test der resultierenden Dateipfade; die Direktiven haben unterschiedliche Semantik. Wird die Variable nur zu Diagnosezwecken geloggt, kann das Entfernen dieses Feldes der kleinere Eingriff sein. Weitere Verwendungen im selben Request-Pfad müssen trotzdem geprüft werden.

Quellen für die Maßnahmen sind die F5-Advisories K000162608, K000162607 und K000162416, deren Workarounds auch in den oben verlinkten CVE-Datensätzen stehen.

Nach einer reinen Konfigurationsänderung:

sudo nginx -t && sudo systemctl reload nginx

Danach kontrollieren, dass der Reload erfolgreich war und alte Worker ihre bestehenden Verbindungen beendet haben. Bei lang laufenden Verbindungen kann der Übergang dauern. Das Abschalten von HTTP/3 allein entschärft diese drei Fehler nicht zuverlässig.

Update einspielen: Reload ist kein Binary-Wechsel

Ein Paketupdate ersetzt zunächst Dateien auf dem Dateisystem. Beim normalen HUP-/Reload-Verfahren startet der bestehende Master neue Worker mit seinem bisherigen Programmcode. Der dokumentierte Wechsel auf eine neue ausführbare Datei ist ein eigener Vorgang. Quelle: NGINX-Prozesssteuerung und Binary-Upgrade.

Für einen üblichen systemd-Host ist nach Installation des bestätigten Fixpakets ein kontrollierter Neustart der einfache Weg, sofern der Paketmanager ihn nicht bereits ausgeführt hat:

# Erst nach dem Paketupdate; Neustart kann Verbindungen unterbrechen
sudo nginx -t && sudo systemctl restart nginx
sudo systemctl --no-pager --full status nginx
sudo journalctl -u nginx --since '-10 minutes' --no-pager

Bei mehreren Proxies nimm jeweils eine Instanz aus dem Traffic, aktualisiere sie und prüfe sie vor der Wiederaufnahme. Falls eure Betriebsabläufe bereits einen getesteten Live-Binary-Upgrade vorsehen, ist dieser ebenfalls möglich. Ein Host-Reboot ist für diese Userspace-Lücken normalerweise nicht nötig.

Bei Containern und Kubernetes erfolgt der Wechsel durch den Rollout des gefixten Images. Prüfe danach alle Replikate, nicht nur das Deployment-Manifest. Bei Plesk und cPanel gehören der Panel-Paketkanal und dessen Service-Verwaltung in denselben Ablauf.

Zur Nachkontrolle gehören neben der laufenden Version die tatsächlich betroffenen Funktionen: SSI-Inhalte, Dateipfade, Weiterleitungen und Access-Logs. Worker-Abstürze, Signale wie SIGSEGV und neue 502-Fehler sind Anlass zur Untersuchung, für sich allein aber noch kein Beweis für einen Angriff.

Einordnung für produktive Systeme

Unsere Priorität wären öffentlich erreichbare Instanzen mit einem der beschriebenen Konfigurationsmuster. Bei einem Shared-Hosting-Server mit vielen generierten vHosts ist die Prüfung aufwendiger als bei einem kleinen Reverse Proxy, aber gerade dort sollte sie nicht bei der globalen nginx.conf enden.

Codeausführung im Worker bedeutet zunächst Zugriff mit dessen Rechten. Das kann bereits Zugang zu Anwendungsverkehr, lesbaren Konfigurationsdateien oder internen Diensten eröffnen. Root auf dem Host folgt daraus nicht automatisch. Umgekehrt sind wiederholte Worker-Abstürze auch ohne RCE ein ernstes Verfügbarkeitsproblem.

Für den Betrieb ergibt sich daraus dieser Ablauf:

Laufende Instanzen, Paketquellen und Container-Images erfassen.
Alle drei CVEs getrennt gegen den konkreten Vendor-Stand prüfen.
Erreichbare Konfigurationspfade priorisieren und bei fehlendem Fix entschärfen.
Fixpaket oder Image ausrollen und den neuen Programmcode tatsächlich starten.
Funktionen, Logs und alle Replikate kontrollieren; Paketversion, Neustart und verbleibende Mitigation dokumentieren.

Wenn die Paketquelle oder die Wirkung generierter Regeln unklar ist, lässt sich das in einem Betriebs- und Security-Check gezielt klären. Gerade bei Panel-Servern ist eine geprüfte Änderung hilfreicher als das pauschale Entfernen von Rewrite-Regeln.

Update-Log

14.10.2026: NGINX veröffentlicht 1.30.6 und 1.31.7; F5 veröffentlicht die drei zugehörigen CVE-Advisories.
15.10.2026, 22:28 Uhr CEST: Erstveröffentlichung dieses Artikels. Technische Ursachen anhand der Upstream-Patches ergänzt, Distributionsstände geprüft und bestätigte Fixes, Testing-Pakete sowie nicht verifizierte Paketkanäle getrennt ausgewiesen.