NGINX-Schwachstellen: Zwei Heap-Overflows mit CVSS 9.2

Zwei NGINX-Schwachstellen mit einem CVSS-Score von 9,2 betreffen sowohl NGINX Open Source als auch NGINX Plus. Am 19. Oktober 2026 wurden zwei Heap-basierte Buffer-Overflows öffentlich gemeldet — CVE-2026-15176 im ngx_http_core_module und CVE-2026-93479 in der String-Expression-Evaluation. Beide sind als ausnutzbar eingestuft. Betroffen sind Betreiber von Webservern, Reverse Proxies und Load Balancern auf NGINX-Basis, also Infrastruktur, die in vielen Setups direkt aus dem Internet erreichbar ist. Ob für die beiden aktuellen Lücken bereits offizielle Patchversionen existieren, ist nicht belegt.

Was die NGINX-Schwachstellen technisch auslösen

Heap-Buffer-Overflows entstehen, wenn ein Prozess mehr Daten in einen reservierten Speicherbereich schreibt, als dieser aufnimmt. Bei NGINX läuft die Verarbeitung einzelner Requests in Worker-Prozessen, deren dynamisch reservierter Speicher im Heap liegt. Als mögliche Folgen gelten der Absturz dieser Prozesse bis hin zur Ausführung eingeschleusten Codes. Ein belastbarer Nachweis, dass sich CVE-2026-15176 oder CVE-2026-93479 tatsächlich zur Codeausführung missbrauchen lassen, liegt bislang nicht vor; „can be exploited“ ist eine Einstufung, kein veröffentlichter Exploit.

Zwei Module, zwei Reichweiten

CVE-2026-15176 sitzt im HTTP-Core-Modul, das in praktisch jeder NGINX-Konfiguration geladen ist. Die Angriffsfläche besteht damit unabhängig davon, ob spezielle Features wie HTTP/3, gRPC-Proxying oder Streaming aktiviert wurden. CVE-2026-93479 betrifft die Auswertung von String-Ausdrücken; welche Direktiven genau davon erfasst sind, bleibt offen. Wer NGINX ausschließlich als statischen Dateiserver einsetzt, ist womöglich weniger exponiert als Konfigurationen mit umfangreichen Rewrite- und Ausdrucksregeln. Das ist eine Einschätzung, die sich aus der Modulzuordnung ergibt — belegt ist sie nicht.

Patch-Lage: für die aktuellen Lücken keine Versionen bestätigt

Für CVE-2026-15176 und CVE-2026-93479 sind keine Fix-Versionen dokumentiert. Mitigationshinweise sind vorhanden; ihr konkreter Inhalt wird hier nicht wiedergegeben. Wer plant, sollte die eingesetzten NGINX-Versionen vor der Prüfung der Herstellerseite erfassen, damit sich ein Patch-Zyklus nicht über mehrere Minor-Stände zieht.

Für ältere Fälle gibt es konkrete Fix-Stände: Für die Lücke CVE-2026-9256 im Rewrite-Modul sind die Fix-Stände 1.30.2, 1.31.1 sowie NGINX Plus 37.0.11, R32 P7 und R36 P5 dokumentiert. Für CVE-2026-42533 ist der Fix auf den 15. Juli 2026 datiert. Diese Konkretheit fehlt aktuell — das ist kein Beleg dafür, dass kein Patch existiert, sondern eine Lücke in der Quellenlage. Admins sollten deshalb nicht auf eine Meldung warten, sondern die F5-Advisory-Seite direkt prüfen.

Was bis zum Patch sinnvoll bleibt

Workarounds für die beiden aktuellen CVEs sind nicht dokumentiert. Praktikabel bleibt zunächst Bestandsaufnahme: Welche NGINX-Instanzen sind aus dem Internet erreichbar, welche terminieren TLS, welche verteilen Last auf Backends? Instanzen mit direkter Exposition gehören zuerst auf die Liste. Ob Rate-Limits oder eine vorgelagerte Proxy-Schicht die Auswirkungen eines Heap-Overflows tatsächlich begrenzen, ist nicht belegt und sollte nicht als Ersatz für einen Patch behandelt werden.

Zwei oder drei Lücken? Die Zahl bleibt offen

Drei Sicherheitslücken werden genannt; dokumentiert sind nur zwei CVE-IDs. Eine dritte Lücke ist nicht identifiziert. Ob es sich um eine separate Schwachstelle, um eine zusammengefasste Zählung oder um einen redaktionellen Fehler handelt, lässt sich derzeit nicht klären. Für die Praxis ist die Unterscheidung relevant, weil sie bestimmt, wie viele Patch-Zyklen und Versionsprüfungen anstehen. Bis zur Klärung gilt: zwei bestätigte CVE-IDs, eine unbestätigte dritte Lücke.

Abgrenzung: Diese NGINX-Lücken gehören nicht zur aktuellen Meldung

Mehrere CVSS-9.x-Fälle rund um NGINX aus dem Jahr 2026 gehören nicht zu CVE-2026-15176 und CVE-2026-93479. Die wichtigsten zur Einordnung:

CVE-2026-42533 (Heap Overflow in der Verarbeitung von map- und Regex-Regeln, CVSS 9.2 nach v4, 8.1 nach v3.1): Die Auswertung erfolgt in zwei Durchläufen, was den Overflow begünstigt — Details zum Two-Pass-Mechanismus. Zum Zeitpunkt der Patch-Veröffentlichung lag kein Hinweis auf Ausnutzung vor. ASLR erschwert zudem die Ausnutzbarkeit.
CVE-2026-42530 (HTTP/3, Use-after-free) und CVE-2026-42055 (Proxy/gRPC), beide mit CVSS 9.2: Sie wurden mit einem Out-of-Band-Patch am 17. Juni 2026 adressiert.
„NGINX Rift" (CVE-2026-42945) im Rewrite-Modul, Scope 0.6.27 bis 1.30.0 sowie Plus R32 bis R36: Hier existiert ein öffentlicher Proof-of-Concept, gefixt in 1.31.0 und 1.30.1.

Diese Abgrenzung ist kein Formalismus. Für CVE-2026-42533 galt explizit, dass keine Hinweise auf Ausnutzung vorlagen — diese Aussage überträgt sich nicht automatisch auf CVE-2026-15176 und CVE-2026-93479. Umgekehrt ist für die beiden aktuellen Lücken kein öffentlicher Exploit dokumentiert, anders als bei „NGINX Rift". Wer die Meldungen vermischt, schätzt das Risiko in beide Richtungen falsch ein.

Fazit: Patchpflicht einplanen, Ausnutzung nüchtern bewerten

Zwei Heap-Overflows mit CVSS 9,2 in einem Modul, das in nahezu jeder NGINX-Installation steckt, sind ein Patch-Grund, kein Alarmfall. Bestätigt ist die Schwachstelle, nicht ihre Ausnutzung in freier Wildbahn. Bestätigt sind zwei CVE-IDs, nicht die drei zunächst genannten Lücken. Und bestätigt ist bislang keine Fix-Version für die aktuellen CVEs — was die dringlichste offene Frage bleibt. Admins sollten Versionsstände erfassen, die F5-Advisory-Seite beobachten und die älteren Lücken aus 2026 separat abarbeiten, statt sie als Teil derselben Welle zu behandeln.

Quellen