F5 patcht außerplanmäßig kritische Nginx-Lücken: HTTP/3-Use-after-free und Heap-Überlauf

Der Hersteller F5 hat am 19. Juni 2026 außerplanmäßig vier Sicherheitslücken in Nginx geschlossen. Zwei davon gelten als kritisch (CVSS 9.2) und ermöglichen unter bestimmten Voraussetzungen das Einschleusen und Ausführen von Schadcode. Der Nginx Ingress Controller bleibt ohne Korrektur, Admins müssen ihre Konfiguration anpassen oder HTTP/3 deaktivieren.

Meldung und Einordnung

Die Schwachstellen betreffen das ngx_http_v3_module, das ngx_http_proxy_v2_module und das ngx_http_grpc_module sowie die Nginx Gateway Fabric. F5 listet die Lücken in einer eigenen Sicherheitsmitteilung auf und stellt ungeplante Aktualisierungen für die betroffenen Produkte bereit. Damit reagiert der Hersteller rund drei Wochen nach dem letzten regulären Patch für Nginx 1.31.2 erneut mit einem Notfall-Update, weil zwei der vier Lücken als kritisch eingestuft sind.

Anders als beim Patch Tüsday im Juni geht es diesmal nicht um eine breite Sammlung von Korrekturen, sondern um eine konzentrierte Reaktion auf zwei Angriffsklassen: Use-after-free im HTTP/3-QUIC-Modul und Heap-Pufferüberlauf im Proxy- und gRPC-Modul. Beide erfordern, dass Angreifer die Maschine ohne vorherige Anmeldung aus dem Netz erreichen können. Der Schadcode wird allerdings nur auf Systemen ohne Adress Space Layout Randomization oder bei Umgehung von ASLR tatsächlich ausgeführt. In Standardumgebungen mit aktivem ASLR führt der Angriff zunächst nur zu einem Neustart des Worker-Prozesses.

Eine Beobachtung aktiver Angriffe in freier Wildbahn gibt es nach Angaben von F5 bislang nicht. Da die Lücken aber technisch leicht reproduzierbar sind und PoC-Codes in ähnlichen Fällen erfahrungsgemäß innerhalb weniger Tage öffentlich werden, empfiehlt F5, die Updates unverzüglich zu installieren.

Technische Details für Admins

Die vier geschlossenen Lücken unterscheiden sich in Angriffsvektor, betroffenem Modul und Schweregrad. Die folgende Tabelle fasst die zentralen Fakten zusammen.

CVE-2026-42530 betrifft Nginx Open Source 1.31.0 bis 1.31.1, ein Fix ist in 1.31.2 enthalten. CVE-2026-42055 betrifft Nginx Plus, Open Source, den Instance Manager, F5 WAF for Nginx, Nginx App Protect WAF, F5 DoS for Nginx, Nginx App Protect DoS, die Nginx Gateway Fabric und den Nginx Ingress Controller in diversen Versionen. Die jeweils konkret gefixten Fassungen sind in der F5-Sicherheitsmitteilung verlinkt.

Der Nginx Ingress Controller ist in allen 3.x-, 4.x- und 5.x-Zweigen verwundbar und erhält keinen Fehlerbehebungs-Patch. Admins müssen HTTP/3 deaktivieren, indem sie in allen listen-Richtlinien den Wert quic entfernen. Damit fällt der HTTP/3-Listener weg, die HTTP/1.1- und HTTP/2-Pfade funktionieren unverändert.

Risiko für KMU und Betrieb

Im typischen KMU-Websetup steht Nginx als Reverse Proxy vor einer oder mehreren Anwendungen, häufig ergänzt um HTTP/2 und seit 2023 zunehmend um HTTP/3. Wird HTTP/3 nicht bewusst aktiviert, sind die Use-after-free-Lücken zwar nicht direkt erreichbar, doch in vielen Container-Setups und Helm-Charts für den Nginx Ingress Controller ist die QUIC-Unterstützung in der Standardkonfiguration enthalten. Wer seinen Ingress mit --enable-nginx-quic ausgerollt hat, ist mit hoher Wahrscheinlichkeit betroffen.

Das Heap-basierte Pufferüberlauf-Problem CVE-2026-42055 ist im Proxy-Modul verankert, das in nahezu jeder produktiven Nginx-Konfiguration aktiv ist. Es wird über manipulierte HTTP-Anfragen ausgelöst. Standard-Distributionen aktivieren ASLR in der Regel, sodass der Schaden zunächst auf einen Worker-Neustart begrenzt bleibt. In gehärteten Umgebungen wie Container-Images mit deaktiviertem ASLR, Embedded-Plattformen oder älteren Linux-Kernels ohne ASLR-Patches ist die Schwelle für tatsächliche Schadcodeausführung allerdings deutlich niedriger.

Die zwei hochriskanten Lücken in der Nginx Gateway Fabric (CVE-2026-11311, CVE-2026-50107) erfordern einen authentifizierten Angreifer, sind für Plattformen mit Kubernetes-Operator aber ebenfalls relevant. Wer die Gateway Fabric einsetzt, um CRDs für NginxProxy zu definieren, sollte das RBAC-Setup überprüfen, damit nur autorisierte Service-Accounts CRDs schreiben dürfen.

Was Admins jetzt prüfen sollten

1. HTTP/3-Status ermitteln. In jeder Nginx-Konfiguration prüfen, ob das quic-Schlüsselwort in einer listen-Direktive aktiv ist. nginx -T 2>/dev/null | grep -n quic listet die Treffer.
2. Patch auf Nginx 1.31.2 oder neuer einspielen. Für CVE-2026-42530 enthält Nginx Open Source 1.31.2 bereits einen Fix. Wer eine Distribution mit eigenem Nginx-Paket einsetzt, muss die jeweils gefixten Versionen des Herstellers einspielen.
3. Nginx Ingress Controller absichern. In allen 3.x-, 4.x- und 5.x-Zweigen fehlt ein Patch. Workaround: HTTP/3 in den listen-Direktiven der Ingress-Ressourcen deaktivieren, bis die korrigierte Version vorliegt.
4. Nginx Plus und WAF-Module aktualisieren. Für CVE-2026-42055 sind F5-Produkte eigenständig zu patchen, insbesondere F5 WAF for Nginx, Nginx App Protect WAF, F5 DoS for Nginx und Nginx App Protect DoS.
5. Gateway Fabric auf 2.6.4 anheben. Wer die Nginx Gateway Fabric in Version 2 einsetzt, erhält mit 2.6.4 die Korrekturen für CVE-2026-11311 und CVE-2026-50107. Frühere 2.x-Versionen erhalten keinen Patch.
6. ASLR in Container-Images verifizieren. Prüfen, ob Nginx-Container mit personality(ADDR_NO_RANDOMIZE), seccomp-Profilen ohne ASLR oder direkt mit setarch -R nginx gestartet werden. In solchen Images wirkt die Schutzfunktion nicht und der Schadcode-Pfad ist direkt erreichbar.
7. Monitoring und WAF prüfen. Nginx-Status, Worker-Restarts und 5xx-Anteile in den letzten 30 Tagen auswerten. Ungewöhnliche Neustart-Spitzen könnten auf einen bereits stattgefundenen Angriffsversuch hinweisen.

Betriebscheck nach der Meldung

1. Ist auf allen produktiven Nginx-Instanzen HTTP/3 bewusst aktiviert oder nur über das Standard-Image übernommen worden?
2. Welche Ingress-Controller-Versionen laufen im Cluster, und sind in deren Standard-Config quic-Direktiven enthalten?
3. Werden Nginx-Container in Kubernetes, Docker oder Podman mit aktivem ASLR betrieben, oder existieren Images ohne ASLR-Schutz?
4. Gibt es eine zentrale Konfigurationsverwaltung für Nginx, mit der HTTP/3-Patches unternehmensweit ausgerollt werden können?
5. Liegen im F5-Account die richtigen Lizenzen für die aktualisierten Plus- und WAF-Pakete bereit, sodass der Rollout nicht an einer Lizenzsperre scheitert?
6. Wurde die Gateway-Fabric-Version in den letzten drei Monaten erfasst, damit ein Upgrade auf 2.6.4 kurzfristig möglich ist?

Admin-Einschätzung

Die außerplanmäßigen Nginx-Patches sind in zweierlei Hinsicht bemerkenswert. Erstens kommen sie nur drei Wochen nach dem regulären Patch Tüsday, was darauf hindeutet, dass F5 in den eigenen Produkten oder bei großen Kunden auf konkrete Angriffsszenarien reagiert. Zweitens bleibt der Nginx Ingress Controller ohne Korrektur, was Administratoren zwingt, HTTP/3 zu deaktivieren und damit den modernsten Pfad der HTTP-Spezifikation temporär aufzugeben.

Pragmatisch empfehle ich folgende Reihenfolge: zunächst den HTTP/3-Status pro Instanz mit nginx -T | grep quic und im Cluster mit kubectl get ingress -o yaml | grep quic erfassen. Dann Nginx Open Source auf 1.31.2 (oder die jeweils gefixte Distribution-Version) heben, parallel die Plus- und WAF-Module aktualisieren. Wo der Nginx Ingress Controller im Spiel ist, HTTP/3 deaktivieren, bis F5 eine korrigierte Version veröffentlicht. Wer die Gateway Fabric in Version 2 einsetzt, plant das Upgrade auf 2.6.4 im nächsten Wartungsfenster. Mit dem Wissen um CVE-2026-42530 und CVE-2026-42055 lässt sich das Risiko in den meisten Umgebungen sauber auf "Worker-Restart" reduzieren, solange ASLR aktiv bleibt.

Passende Anleitungen auf S-EDV

1. nginx 1.31.2 schließt kritische Lücken in HTTP/3, gRPC und Charset Modul – Vorgeschichte aus dem Juni-Patchday mit ergänzenden Details zur HTTP/3-Konfiguration.
2. Nginx als Reverse Proxy mit TLS manüll einrichten – Schritt-für-Schritt-Anleitung für eine saubere Basiskonfiguration ohne unsichere Defaults.
3. Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only – liefert das Grundgerüst für sichere Nginx-Container inklusive non-root-Setups.

Quellen

1. heise online: F5 patcht außerplanmäßig kritische Nginx-Sicherheitslücken (19.06.2026)
2. heise online (englische Fassung): F5 patches out-of-band critical Nginx security vulnerabilities
3. F5 Security Advisory K000157000: Nginx security vulnerabilities
4. NVD: CVE-2026-42530 (Use-after-free in ngx_http_v3_module)
5. NVD: CVE-2026-42055 (Heap-basierter Pufferüberlauf in ngx_http_proxy_v2 und ngx_http_grpc)