Kritische RCE-Risiken in NGINX: Details zu CVE-2026-42530 und 42055

F5 hat Sicherheitsupdates veröffentlicht, die zwei kritische Schwachstellen in NGINX Open Source und verwandten Produkten beheben. Beide Schwachstellen – CVE-2026-42530 und CVE-2026-42055 – wurden mit einem CVSS v4 9.2 bewertet und ermöglichen einem entfernten, nicht authentifizierten Angreifer unter bestimmten Konfigurationen die Ausführung beliebigen Codes. Betroffen ist eine breite Palette von Produkten: von NGINX Open Source und NGINX Plus über NGINX Ingress Controller, Gateway Fabric, Instance Manager bis hin zu WAF/DoS-Komponenten. Administratoren wird dringend empfohlen, betroffene Installationen umgehend auf die behobenen Versionen zu aktualisieren oder die vorgeschlagenen Mitigationsmaßnahmen umzusetzen.

Technische Analyse der Schwachstellen

CVE-2026-42530: use-after-free im HTTP/3-Modul

Die Schwachstelle vom Typ use-after-free wurde im Modul ngx_http_v3_module entdeckt. Laut dem F5-Sicherheitshinweis ist eine Ausnutzung möglich, wenn NGINX für die Verwendung des HTTP/3-QUIC-Moduls konfiguriert ist. Ein Angreifer kann über eine speziell aufgebaute HTTP/3-Sitzung den QPACK-Encoder-Stream erneut öffnen, was zu einem Zugriff auf bereits freigegebenen Speicher führt. Die Ausführung beliebigen Codes ist auf Systemen möglich, auf denen ASLR (Address Space Layout Randomization) deaktiviert ist oder wenn der Angreifer eine Möglichkeit hat, ASLR zu umgehen.

Betroffene Produkte:

• NGINX Open Source 1.31.0 – 1.31.1 (behoben in 1.31.2)
• NGINX Gateway Fabric 2.0.0 – 2.6.3 (behoben in 2.6.4)
• NGINX Gateway Fabric 1.3.0 – 1.6.2 (behobene Version nicht angegeben)
• NGINX Instance Manager 2.17.0 – 2.22.0 (behobene Version nicht angegeben)
• NGINX Ingress Controller 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.5.0 (behobene Versionen nicht angegeben)

CVE-2026-42055: heap-based buffer overflow in HTTP/2-Modulen

Die zweite Schwachstelle ist ein heap-based buffer overflow (Überlauf des Heapspeichers) in den Modulen ngx_http_proxy_v2_module und ngx_http_grpc_module. Wie im entsprechenden F5-Hinweis angegeben, ist für eine Ausnutzung das gleichzeitige Vorliegen mehrerer Bedingungen erforderlich: die Verwendung der Direktive proxy_http_version 2 oder grpc_pass zum Proxying von HTTP/2-Traffic, das Setzen der Direktive ignore_invalid_headers auf den Wert off sowie eine Größe des Puffers large_client_header_buffers, die 2 MB überschreitet. Wie bei der ersten Schwachstelle ist die Codeausführung möglich, wenn ASLR deaktiviert ist oder umgangen werden kann.

Diese Schwachstelle betrifft eine deutlich größere Zahl von Produkten:

• NGINX Open Source 1.31.1 (behoben in 1.31.2)
• NGINX Open Source 1.30.0 – 1.30.2 (behoben in 1.30.3)
• NGINX Plus 37.0.0 – 37.0.1 (behoben in 37.0.2.1)
• NGINX Plus R33 – R36 (behoben in R36 P6)
• NGINX Gateway Fabric 2.0.0 – 2.6.3 (behoben in 2.6.4)
• NGINX Gateway Fabric 1.3.0 – 1.6.2
• NGINX Instance Manager 2.17.0 – 2.22.0
• F5 WAF for NGINX 5.9.0 – 5.13.1
• NGINX App Protect WAF 4.10.0 – 4.16.0, 5.2.0 – 5.8.0
• F5 DoS for NGINX 4.9.0
• NGINX App Protect DoS 4.3.0 – 4.7.0
• NGINX Ingress Controller 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.5.0

Die Einträge im CVE-Register sind unter folgenden Links verfügbar: CVE-2026-42530 und CVE-2026-42055.

Bewertung des praktischen Risikos

Trotz der hohen CVSS-Bewertungen von 9.2 wird die praktische Ausnutzung beider Schwachstellen durch eine Reihe von Faktoren eingeschränkt. Für CVE-2026-42530 muss in der Konfiguration das HTTP/3-QUIC-Modul aktiviert sein – eine Funktionalität, die in den meisten NGINX-Deployments bislang nicht zum Standard gehört. Für CVE-2026-42055 ist eine noch spezifischere Kombination erforderlich: HTTP/2-Proxying, explizite Deaktivierung der Header-Validierung und ein untypisch großer Puffer.

Darüber hinaus setzt die Codeausführung in beiden Fällen ein deaktiviertes ASLR oder dessen Umgehung voraus – auf modernen Linux-Systemen ist ASLR standardmäßig aktiviert.

F5 berichtet bislang nicht über eine Ausnutzung dieser Schwachstellen in realen Angriffen. Keine der beiden CVEs ist im CISA-KEV-Katalog aufgeführt. Dennoch sind Produkte von F5 und NGINX erfahrungsgemäß ein attraktives Ziel für Angreifer, da sie weitverbreitet als Reverse-Proxy-Server, Load-Balancer sowie als Einstiegspunkte in Unternehmensnetze und Kubernetes-Cluster eingesetzt werden.

Besondere Aufmerksamkeit ist in Organisationen erforderlich, die NGINX in Kubernetes-Umgebungen über NGINX Ingress Controller oder NGINX Gateway Fabric einsetzen: Die Kompromittierung dieser Komponenten kann einem Angreifer Zugriff auf den gesamten durch den Cluster laufenden Traffic verschaffen.

Empfehlungen zur Behebung

Vorrangige Maßnahme ist die Aktualisierung auf die behobenen Versionen:

• NGINX Open Source: Aktualisierung auf 1.31.2 (mainline) oder 1.30.3 (stable)
• NGINX Plus: Aktualisierung auf 37.0.2.1 oder Installation von R36 P6
• NGINX Gateway Fabric: Aktualisierung auf 2.6.4

Wenn ein sofortiges Update nicht möglich ist, schlägt F5 folgende Mitigationsmaßnahmen vor:

• Für CVE-2026-42530: Deaktivieren von HTTP/3 in der NGINX-Konfiguration
• Für CVE-2026-42055: Entfernen der Direktive ignore_invalid_headers off aus der Konfiguration (standardmäßig ist die Header-Validierung aktiviert) oder Reduzieren der Größe von large_client_header_buffers auf einen Wert unter 2 MB

Für einige betroffene Produkte – NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS und bestimmte Ingress-Controller-Zweige – sind in den Hinweisen bislang keine behobenen Versionen genannt. Administratoren dieser Produkte sollten die Updates der Hinweise K000161616 und K000161584 verfolgen und als temporäre Maßnahme die oben beschriebenen Konfigurationsänderungen umsetzen.

Angesichts des kritischen Schweregrads der Schwachstellen und der großen Zahl betroffener Produkte sollten Organisationen zunächst die NGINX-Konfigurationen auf den Einsatz von HTTP/3 QUIC und ungewöhnliche HTTP/2-Proxy-Einstellungen prüfen und anschließend ein Update im Rahmen des nächsten Wartungsfensters planen. In Kubernetes-Deployments ist die Priorität für Updates von Ingress Controller und Gateway Fabric zu erhöhen, da diese Komponenten den gesamten eingehenden Cluster-Traffic verarbeiten.