Fünf NGINX-Sicherheitslücken wurden behoben, doch das Ausmaß der Gefährdung hängt von den Serverkonfigurationen ab. Drei Schwachstellen zur Speicherbeschädigung könnten unter bestimmten Bedingungen die Ausführung von Code aus der Ferne ermöglichen.
F5 veröffentlichte am 14. Oktober 2026 entsprechende Korrekturen und behob damit neben den Speicherfehlern auch Schwachstellen durch HTTP/3-Request-Injection und die Fälschung von TLS-Sitzungen. Die Updates sind in den NGINX-Open-Source-Versionen 1.30.6 und 1.31.7 verfügbar; für betroffene Enterprise-Produkte gibt es entsprechende Patches.
Administratoren, die Webserver, Reverse-Proxys und Kubernetes-Infrastrukturen verwalten, müssen die installierten Versionen und aktivierten Funktionen überprüfen. Die von der Konfiguration abhängige Gefährdung erschwert auch die Behebung der aktuellen NetScaler-Authentifizierungsschwachstellen, bei denen betroffene Bereitstellungen mehr als eine Überprüfung der Softwareversion erfordern.
Fünf NGINX-Schwachstellen und die betroffenen Konfigurationen
Die NGINX-Sicherheitsbulletins stufen alle fünf Schwachstellen als mittelschwer ein. F5 weist den drei Schwachstellen zur Speicherbeschädigung hingegen kritische CVSS-4.0-Werte von 9,2 zu.
| CVE | Schwachstelle | Betroffene Konfiguration |
|---|---|---|
| CVE-2026-15176 | Pufferüberlauf im Heap | alias und rewrite bei bestimmten Verwendungen von $request_filename |
| CVE-2026-93479 | Pufferüberlauf im Heap | Vorzeitige Regex-mapCapture-Referenzen oder bestimmte nicht cachefähige Variablenausdrücke |
| CVE-2026-97205 | Use-after-free | Asynchrone Datei-E/A mit virtuellen SSI-Includes |
| CVE-2026-95101 | Injection in den HTTP/3-Request-Body | HTTP/3 mit betroffenem Buffering von Proxy-Requests |
| CVE-2026-97629 | Fälschung von TLS-Sitzungen | Gemeinsam genutzter TLS-Sitzungscache mit automatischer Rotation der Ticket-Schlüssel |
Die drei Schwachstellen zur Speicherbeschädigung könnten NGINX-Worker-Prozesse zum Absturz bringen. Eine Ausführung von Code aus der Ferne könnte ebenfalls möglich sein, wenn die Address Space Layout Randomization (ASLR) deaktiviert oder umgangen wurde.
Der von F5 veröffentlichte technische Hinweis identifiziert die alias, rewrite, sowie die $request_filename Kombination hinter CVE-2026-15176. CVE-2026-93479 betrifft die vorzeitige Auswertung von Variablen, während CVE-2026-97205 asynchrone E/A in Verbindung mit Server Side Includes (SSI) unter Verwendung virtueller Includes betrifft.
Die übrigen Schwachstellen betreffen die Verarbeitung von Requests und die Authentifizierung. CVE-2026-95101 könnte unbeabsichtigte Daten aus dem Request-Body an Backend-Anwendungen weiterleiten, während CVE-2026-97629 unter bestimmten, nicht deterministischen Bedingungen die Fälschung von TLS-Sitzungen und die Umgehung der Client-Zertifikatsprüfung ermöglichen könnte. In den bis zum 20. Oktober 2026 geprüften Quellen fanden sich keine öffentlich bestätigten Hinweise auf eine Ausnutzung dieser fünf Schwachstellen.
NGINX patchen und die Angriffsfläche reduzieren
Administratoren sollten NGINX Open Source auf die stabile Version 1.30.6 oder die Mainline-Version 1.31.7 aktualisieren. Kunden von NGINX Plus sollten die produktspezifischen Patch-Hinweise befolgen, während Kubernetes-Betreiber den NGINX Ingress Controller 5.7.0 oder das jeweils geeignete unterstützte Long-Term-Support-Update bereitstellen sollten.
Sicherheitsteams sollten internetseitig erreichbare Installationen priorisieren und folgende Maßnahmen ergreifen:
- Installationen patchen und überprüfen: Unterstützte Korrekturen anwenden, Versionen mit
nginx -vbestätigen und auf zurückportierte Patches prüfen. Zuvor unwirksame Sicherheitsupdates unterstreichen, wie wichtig die Überprüfung der Behebung ist. - Gefährdete Konfigurationen prüfen:
nginx -Tverwenden, um die relevantenalias,rewrite,map, AIO-, SSI-, HTTP/3- und TLS-Sitzungscache-Einstellungen zu überprüfen. - Vorübergehende Gegenmaßnahmen anwenden: Deaktivieren Sie gegebenenfalls HTTP/3 oder nicht verwendete SSI-/AIO-Funktionen, überprüfen Sie die TLS-Ticket-Einstellungen und korrigieren Sie gefährliche Kombinationen von Direktiven.
- Backend-Zugriff beschränken: Beschränken Sie Verbindungen zu Anwendungsservern auf autorisierte Proxys und vertrauenswürdige Netzwerke.
- Auf verdächtige Aktivitäten achten: Untersuchen Sie unerwartete Abstürze von Worker-Prozessen, ungewöhnliche Aktivitäten im Request-Body und Anomalien bei der TLS-Authentifizierung. Die aktuelle Ausnutzung einer WordPress-RCE-Schwachstelle zeigt ebenfalls, wie wichtig eine Prüfung auf Kompromittierung nach dem Patchen ist.
- Pläne für die Reaktion auf Vorfälle testen: Überprüfen Sie Eskalationswege, die Sicherung von Beweismitteln, Rollback-Verfahren und die Wiederherstellung des Dienstes.
Konfigurationsänderungen sollten vor der Bereitstellung in der Produktion getestet werden. Das Patchen bleibt die wichtigste Maßnahme, gefolgt von der Überprüfung, dass die betroffenen Dienste und Authentifizierungsmechanismen ordnungsgemäß funktionieren.
Weiterführende Lektüre: Citrix hat außerdem eine kritische NetScaler-RCE-Schwachstelle gepatcht , die bestimmte SAML-Konfigurationen betrifft – ein weiteres Beispiel dafür, warum Versionsprüfungen mit Konfigurationsbewertungen kombiniert werden müssen.