Fünf NGINX-Schwachstellen in 1.30.6 und 1.31.7 behoben
Fünf NGINX-Schwachstellen, die bestimmte Webserver-Konfigurationen betreffen, wurden in der stable version 1.30.6 und der mainline version 1.31.7 behoben. NGINX veröffentlichte beide Updates am 14. Oktober. Drei Fehler können Speicher beschädigen, einen Worker-Prozess zum Absturz bringen und möglicherweise remote code execution (RCE) ermöglichen, sodass ein Angreifer Software auf dem Server ausführen könnte. Eine weitere Schwachstelle könnte eine Transport Layer Security (TLS)-Session fälschen und die client-certificate verification umgehen, während die fünfte unbeabsichtigte Daten in einen HTTP/3-Request einfügen kann, der an eine Backend-Anwendung gesendet wird.
NGINX stuft alle fünf Schwachstellen mit mittlerem Schweregrad ein. F5, das Unternehmen hinter NGINX, bewertete die drei Speicherfehler nach dem Common Vulnerability Scoring System Version 4.0 mit dem kritischen Wert 9,2. Das TLS-Problem erhielt den Wert 8,3 und das HTTP/3-Problem den Wert 6,9. Mit Stand vom 15. Oktober war keine der Schwachstellen im Known Exploited Vulnerabilities-Katalog der US Cybersecurity and Infrastructure Security Agency aufgeführt, und weder NGINX noch F5 hatten über damit verbundene Angriffe berichtet. Ein Fehler betrifft Releases bis zurück zum Mai 2005, doch jede Schwachstelle setzt eine bestimmte Konfiguration voraus, statt standardmäßig jede NGINX-Installation zu gefährden.
CVE-2026-15176 betrifft die Versionen 0.1.29 bis 1.31.6. Die Schwachstelle kann einen heap overflow verursachen, wenn eine location alias verwendet, ein rewrite die URI des Requests ändert und eine Direktive wie return, set, if, add_header oder das access log $request_filename liest, bevor NGINX die nächste location auswählt. Ist das Präfix dieser location länger als die umgeschriebene URI, kann die Umwandlung der URI in einen Dateipfad die Grenzen ihres Speicherpuffers überschreiten. F5 empfiehlt, alias in dieser location zu vermeiden und $request_filename erst wieder zu verwenden, wenn ein Upgrade möglich ist.
CVE-2026-93479 ist ein weiterer heap overflow, der über eine map mit regulärem Ausdruck erreicht wird, deren erfasste Werte von root oder log_format vor der Ausgabevariable der map verwendet werden. Als betroffen gelten die Versionen 1.30.0 bis 1.30.5 und 1.31.2 bis 1.31.6. Die anfällige String-Verarbeitung war zuvor für CVE-2026-42533 geändert worden, wofür NGINX am 15. Juli einen Patch veröffentlichte. Der späteren Fehlerbehebung zufolge verhinderte eine Änderung vom Juli einen Pufferüberlauf, ließ jedoch weiterhin zu, dass Daten in reservierten Speicher gelangten, während eine andere Änderung die endgültige String-Größe anhand dieser überzähligen Länge berechnete. Der nun behobene Overflow war auf den reservierten Bereich des document-root-Pfads und auf ein Nullbyte im access-log-Pfad beschränkt. Obwohl die aufgeführten betroffenen Versionen bereits vor der Änderung vom Juli beginnen, bleibt jeder mit dem Juli-Release aktualisierte Server innerhalb der betroffenen Versionsbereiche. F5 empfiehlt vorübergehend, named captures nur innerhalb des Blocks zu verwenden, der den passenden Ausdruck enthält. Ein Sicherheitsforscher erklärte The Hacker News jedoch im Juli, dass ein Upgrade die einzige vollständige Lösung für das frühere Problem sei.
CVE-2026-97205 ist eine use-after-free-Schwachstelle, die die Versionen 0.8.11 bis 1.31.6 betrifft, wenn asynchronous input and output (AIO) aktiviert ist und Server Side Includes (SSI)-Seiten in bestimmten Konfigurationen include virtual-Befehle verwenden. Jeder noch nicht abgeschlossene asynchrone Vorgang erhöht einen 8-Bit-Zähler. Bei 256 ausstehenden Vorgängen springt der Zähler auf null zurück, wodurch ein Request freigegeben werden kann, obwohl Vorgänge weiterhin auf dessen Speicher verweisen. Die Folge kann ein Absturz, eine Speicherbeschädigung oder eine mögliche Codeausführung sein. Administratoren, die kein Update durchführen können, können AIO deaktivieren oder die Bereitstellung von SSI-Seiten einstellen.
CVE-2026-95101 betrifft HTTP/3-Deployments mit den Versionen 1.25.0 bis 1.31.6, bei denen proxy_request_buffering aktiviert ist, was der Standardeinstellung entspricht. Ein Parser-Feld wurde sowohl dazu verwendet, die verbleibende Größe eines unbekannten, zu überspringenden Frames zu verfolgen, als auch dazu, die Bytes des Request-Bodys zu zählen. Wenn dieser Frame über zwei Lesevorgänge verteilt eintraf, konnte NGINX den verbleibenden Zählerstand als Body-Daten behandeln und zusätzliche Bytes an das Backend weiterleiten, ohne dass diese von der client_max_body_size-Prüfung erfasst wurden. Der Workaround von F5 besteht darin, proxy_request_buffering auf off zu setzen. Die NGINX-Dokumentation empfiehlt normalerweise Request-Buffering. Daher ist es für Betreiber von HTTP/3 wichtig, das korrigierte Release zu installieren, anstatt den Workaround auf unbestimmte Zeit beizubehalten.
CVE-2026-97629 betrifft die Versionen 1.23.2 bis 1.31.6, wenn ssl_session_cache einen shared cache verwendet und keine ssl_session_ticket_key-Datei konfiguriert ist. Seit Version 1.23.2 vom Oktober 2022 führt diese Kombination dazu, dass NGINX automatisch TLS session ticket keys erstellt und rotiert. Jeder Worker behält drei key slots, bei der Rotation wurden jedoch nur zwei davon kopiert. Der dritte konnte daher nicht initialisierten Speicher enthalten, und ein Ticket, das auf diesen Slot verwies, konnte mit diesen unbeabsichtigten Inhalten geprüft und entschlüsselt werden. F5 zufolge ist die daraus entstehende session forgery nicht deterministisch und liegt außerhalb der Kontrolle eines Angreifers, könnte jedoch die client-certificate verification umgehen. Die shared-cache-Konfiguration ist in der NGINX-eigenen Dokumentation aufgeführt. Websites, die kein Update durchführen können, können den shared cache entfernen, ticket keys über ssl_session_ticket_key bereitstellen oder ssl_session_tickets auf off setzen. NGINX behob im Februar 2025 mit CVE-2025-23419 ein früheres Problem bei der Wiederverwendung von Sessions, das ebenfalls eine Umgehung der Zertifikatsprüfung ermöglichen konnte.
Administratoren sollten auf dem stable branch Version 1.30.6 oder auf mainline Version 1.31.7 installieren. Das stable release enthält ausschließlich Fehlerbehebungen. NGINX veröffentlicht Sicherheitskorrekturen für diese beiden Branches. Ältere Branches wie 1.28 bleiben daher innerhalb der betroffenen Versionsbereiche, sofern eine Linux-Distribution die Patches nicht in ihr Paket backported hat. Nutzer von NGINX Plus sowie Betreiber von F5 Ingress Controller, Gateway Fabric, Instance Manager oder WAF-Produkten sollten die Produkthinweise von F5 lesen. Diese Hinweise führten betroffene Builds auf und nannten mit Stand vom 15. Oktober für mehrere Produkte noch keinen korrigierten Build.
Eine praktische Überprüfung beginnt damit, die aktive Konfiguration mit nginx -T auszugeben und nach alias in Kombination mit rewrite, von root oder log_format verwendeten maps mit regulären Ausdrücken, aio zusammen mit ssi, listen-Direktiven mit quic sowie einem shared ssl_session_cache ohne ssl_session_ticket_key zu suchen. Kunden verwalteter Dienste, die dies nicht selbst prüfen können, sollten ihren Hosting-Anbieter bitten, das installierte NGINX-Release zu bestätigen und anzugeben, ob die Patches backported wurden. Für Betreiber von WordPress-Websites, die einen verwalteten Betrieb in Betracht ziehen, bietet AEU Hosting vollständig abgesichertes Managed WordPress Hosting an.
Dies war das achte Sicherheitsrelease von NGINX im Jahr 2026. Die Dringlichkeit wird durch einen separaten Overflow im rewrite module, CVE-2026-42945, unterstrichen. VulnCheck stellte fest, dass dieser bereits wenige Tage nach seiner Offenlegung ausgenutzt wurde, nachdem NGINX ihn im Mai gepatcht hatte. F5 entdeckte den alias-Fehler und schrieb weitere Meldungen Forschern mit Verbindungen zu Tolmo und GOTROOT, PhiNode Labs sowie einem weiteren Forscher zu. Am selben Tag veröffentlichte NGINX außerdem njs 1.0.2, um zwei XML-Verarbeitungsschwachstellen mittleren Schweregrads zu beheben: CVE-2026-101025 und CVE-2026-101019.