Security 18.06.2026 Aktualisiert: 29.06.2026

NGINX CVE-2026-42055/CVE-2026-42530: HTTP/2, gRPC und HTTP/3 prüfen

Zwei NGINX-Lücken betreffen HTTP/2/gRPC-Upstreams und HTTP/3. Prüfe Versionen, Distro-Fixes, Konfiguration und Mitigation.

Stand: 29.06.2026, 08:45 Uhr CEST. F5 und NGINX haben am 17.06.2026 neue NGINX-Versionen für mehrere Schwachstellen veröffentlicht. Für den Betrieb sind zwei Lücken besonders relevant: CVE-2026-42055 in HTTP/2-/gRPC-Upstream-Konfigurationen und CVE-2026-42530 im HTTP/3-/QUIC-Modul. Die Lage ist nicht für beide CVEs gleich: CVE-2026-42055 betrifft viele klassische Distributionspakete, während CVE-2026-42530 bei vielen Distributionen als nicht betroffen gilt, weil der verwundbare HTTP/3-Code dort nicht vorhanden ist.

Kurzfassung

CVE-2026-42055: Heap-Buffer-Overflow beim Proxying zu HTTP/2- oder gRPC-Upstreams. Remote triggerbar, aber nur mit bestimmten NGINX-Direktiven: proxy_http_version 2 oder grpc_pass, ignore_invalid_headers off und large_client_header_buffers größer als 2 MB.
CVE-2026-42530: Use-after-free im ngx_http_v3_module. Remote triggerbar über HTTP/3/QUIC, aber nur in NGINX Open Source 1.31.0 und 1.31.1 mit aktivem HTTP/3.
Upstream-Fixes: 1.30.3 stable fixt CVE-2026-42055. 1.31.2 mainline fixt CVE-2026-42055 und CVE-2026-42530. CVE-2026-42530 betrifft laut NGINX nur 1.31.0 bis 1.31.1.
RCE oder DoS: Beide Lücken können Worker-Crashes verursachen. Codeausführung ist laut Vendor-Beschreibung bei deaktivierter oder umgangener ASLR möglich, in modernen Standardsetups aber deutlich schwerer als ein Worker-Neustart.
Distro-Unterschiede: Debian stable war für CVE-2026-42055 zum geprüften Stand noch als verwundbar markiert, Ubuntu nennt konkrete Fixversionen, Red Hat markiert RHEL 8/9/10 für CVE-2026-42055 als affected. Für CVE-2026-42530 stehen Debian, Ubuntu, RHEL und SUSE überwiegend auf not affected.
Schnelle Mitigation für CVE-2026-42055: ignore_invalid_headers on setzen oder large_client_header_buffers auf maximal 2 MB reduzieren. Besser: auf einen gefixten NGINX-Stand aktualisieren.
Schnelle Mitigation für CVE-2026-42530: HTTP/3 deaktivieren, also quic aus listen-Direktiven entfernen, bis 1.31.2 oder ein Vendor-Backport aktiv ist.

Warum zwei CVEs in einem Artikel?

Die beiden Lücken wurden zusammen öffentlich sichtbar, betreffen aber unterschiedliche Codepfade.

CVE	Bereich	Typische betroffene Setups	Upstream-Fix
CVE-2026-42055	`ngx_http_proxy_v2_module` und `ngx_http_grpc_module`	Reverse Proxies zu HTTP/2-Upstreams, gRPC-Gateways, API-Frontends mit ungewöhnlich großen Header-Buffern	`1.30.3` und `1.31.2`
CVE-2026-42530	`ngx_http_v3_module`	NGINX Open Source mainline `1.31.0`/`1.31.1` mit HTTP/3/QUIC auf UDP 443	`1.31.2`

Das ist in der Praxis wichtig. Viele Admins sehen die Meldung “zwei kritische NGINX-Lücken” und patchen pauschal. Das ist als Richtung richtig, aber für Risiko und Priorisierung zu grob. Ein Debian- oder RHEL-Server ohne HTTP/3 kann für CVE-2026-42530 nicht betroffen sein, während CVE-2026-42055 trotzdem offen bleibt. Ein selbst gebauter Mainline-NGINX mit HTTP/3 kann dagegen beide Themen gleichzeitig haben.

Wie funktioniert CVE-2026-42055?

CVE-2026-42055 sitzt im Weg von NGINX zu einem HTTP/2- oder gRPC-Upstream. Der Client spricht mit NGINX, NGINX baut daraus eine Upstream-Anfrage und codiert Header für HTTP/2 beziehungsweise gRPC. Gefährlich wird es, wenn drei Dinge zusammenkommen:

ignore_invalid_headers off;
large_client_header_buffers 4 3m;

location /grpc.Service/ {
  grpc_pass grpc://backend;
}

oder:

ignore_invalid_headers off;
large_client_header_buffers 4 3m;

location /api/ {
  proxy_http_version 2;
  proxy_pass http://backend;
}

Die Werte sind Beispiele, keine Empfehlung. Der entscheidende Punkt ist die Kombination aus akzeptierten “invalid” Headers, sehr großen Client-Header-Buffern und einem HTTP/2- oder gRPC-Upstream-Pfad.

Bei normalen Defaults liegt large_client_header_buffers weit unter 2 MB. Viele Standardserver sind deshalb nicht durch die Default-Konfiguration betroffen. Riskant sind Setups, die Header-Limits stark angehoben haben, etwa wegen großer Tokens, Legacy-Clients, SSO-Konstrukten, API-Gateways oder interner Kompatibilitätsprobleme.

Technisch geht es um eine Längen- und Pufferannahme beim Erzeugen der Upstream-Header. Ein Angreifer kann große Header senden, NGINX verarbeitet sie wegen der Konfiguration weiter und baut daraus eine HTTP/2-/gRPC-Anfrage. In der fehlerhaften Logik kann dabei ein Heap-Puffer zu klein ausfallen. Das Ergebnis ist Speicherbeschädigung im Worker-Prozess.

Praktisch heißt das:

Ein Angreifer braucht keinen Login.
Der NGINX-Server muss aber die passende Konfiguration haben.
Der Angriff kommt über den öffentlichen HTTP(S)-Pfad, nicht über direkten Zugriff auf den Backend-Service.
Der zuverlässigste sichtbare Effekt ist ein Worker-Neustart oder Crash.
RCE ist laut Vendor-Beschreibung möglich, wenn ASLR deaktiviert ist oder umgangen wird.

Wie funktioniert CVE-2026-42530?

CVE-2026-42530 betrifft HTTP/3 über QUIC. Der Fehler sitzt im ngx_http_v3_module und wird über eine speziell gebaute HTTP/3-Sitzung ausgelöst. Der Kern ist ein Use-after-free, wenn ein QPACK-Encoder-Stream erneut geöffnet wird.

HTTP/3 in NGINX erkennst du typischerweise an quic in einer listen-Direktive:

server {
  listen 443 ssl http2;
  listen 443 quic reuseport;
  http3 on;
}

Betroffen ist nach NGINX-Angabe nur NGINX Open Source 1.31.0 und 1.31.1. Ältere stabile Distributionspakete enthalten den konkreten verwundbaren Code oft nicht. Das erklärt, warum Debian, Ubuntu, RHEL und SUSE diese CVE für normale Pakete überwiegend als not affected führen.

Trotzdem gehört der Check in jede Umgebung, in der NGINX nicht aus der Distribution kommt:

selbst gebauter NGINX mainline
Docker-Images mit nginx:mainline
Kubernetes-Ingress-Images mit eigenem NGINX-Build
Appliances oder Panels mit eigenen NGINX-Paketen
Testsysteme, auf denen HTTP/3 früh aktiviert wurde

Wenn HTTP/3 öffentlich auf UDP 443 erreichbar ist und NGINX 1.31.0 oder 1.31.1 läuft, ist die Lage klar: auf 1.31.2 aktualisieren oder HTTP/3 vorübergehend deaktivieren.

Patchstände nach Distribution

Die Tabelle trennt bewusst zwischen beiden CVEs. “Nicht betroffen” bei CVE-2026-42530 heißt nicht automatisch, dass CVE-2026-42055 gefixt ist.

Distribution / Plattform	CVE-2026-42055	CVE-2026-42530	Einordnung
NGINX Open Source stable	Gefixt ab `1.30.3`	Stable `1.30.x` laut NGINX nicht im verwundbaren HTTP/3-Bereich	`1.30.3` einspielen, wenn stable genutzt wird.
NGINX Open Source mainline	Gefixt ab `1.31.2`	Gefixt ab `1.31.2`; verwundbar `1.31.0-1.31.1`	Mainline-Nutzer sollten direkt auf `1.31.2` oder neuer.
Debian Bullseye / Bookworm / Trixie	Zum geprüften Stand im Debian Security Tracker noch vulnerable, auch in Security-Zweigen	Fixed / not affected, verwundbarer Code nicht vorhanden	Für 42055 Vendor-Tracker beobachten oder Mitigation setzen.
Debian Forky / Sid	Gefixt, Tracker nennt `1.30.1-6` als aktuellen Fixstand	Fixed / not affected	Paketstand gegen Tracker prüfen.
Ubuntu 26.04 LTS	Gefixt ab `1.28.3-2ubuntu1.6`	Not affected	`apt upgrade` und Paketstand prüfen.
Ubuntu 25.10	Gefixt ab `1.28.0-6ubuntu1.8`	Not affected	`apt upgrade` und Paketstand prüfen.
Ubuntu 24.04 LTS	Gefixt ab `1.24.0-2ubuntu7.13`	Not affected	`apt upgrade` und Paketstand prüfen.
Ubuntu 22.04 LTS	Gefixt ab `1.18.0-6ubuntu14.16`	Not affected	`apt upgrade` und Paketstand prüfen.
Ubuntu 20.04 / 18.04	Needs evaluation im Ubuntu-Tracker	Not affected	Ubuntu Pro/ESM prüfen; 42055 nicht pauschal abhaken.
RHEL 8/9/10	Red Hat markiert `nginx` und betroffene AppStreams als affected; zum geprüften API-Stand kein RHEL-Fix in `affected_release` sichtbar	Not affected für normale RHEL-NGINX-Pakete	Mitigation setzen oder Red-Hat-Errata beobachten.
AlmaLinux / Rocky / Oracle	Folgen grundsätzlich EL-Paketständen, aber Zeitpunkte können abweichen	In normalen EL-Paketen voraussichtlich nicht betroffen, gegen Vendor prüfen	Nicht blind von RHEL auf alle Klone schließen; eigene Errata prüfen.
SUSE / openSUSE	SUSE markiert viele SLE- und Leap-Produkte als affected; openSUSE Tumbleweed gefixt ab `1.31.2-1.1`	SLE/Leap überwiegend not affected; Tumbleweed mit `1.31.2-1.1` gefixt	SUSE-CVE-Seite pro Produkt und Service Pack prüfen.
Alpine	OSV nennt Fixes für `nginx`, unter anderem `1.28.3-r4` und `1.30.3-r0`	Kein separater Alpine-OSV-Eintrag gefunden; HTTP/3/Mainline-Builds trotzdem prüfen	`apk version -v nginx` gegen Alpine Advisory halten.
Amazon Linux	Amazon Linux listet `nginx` in AL2 Nginx Extras und AL2023 als betroffen; zum geprüften Stand ohne sichtbares Fixed-Datum	Not affected für die sichtbaren Amazon-Linux-Pakete	ALAS-Tracker beobachten und 42055-Konfiguration mitigieren.
Fedora	Bodhi führt NGINX-Updates nach der NGINX-1.30.3-Veröffentlichung	HTTP/3 hängt vom konkreten Fedora-Paketstand ab	`dnf updateinfo info nginx` und Bodhi-Update prüfen.
CloudLinux / cPanel EasyApache	cPanel/EasyApache meldete `ea-nginx`-Updates im Juni, unter anderem für 42055/48142	Je nach Build; HTTP/3 nicht pauschal annehmen	`ea-nginx`, CloudLinux- und cPanel-Kanäle separat prüfen.
Plesk	Plesk nutzt häufig OS-NGINX oder panelverwaltete Komponenten	Je nach aktivem NGINX-Build	OS-Vendor-Update, Plesk-Updates und aktive Binary prüfen.
Container-Images	Hängt vollständig vom Image ab	Hängt vollständig vom Image ab	Images neu bauen und laufende Pods/Container ersetzen.

Die unbequemste Zeile ist Debian: Für CVE-2026-42055 waren Bullseye, Bookworm und Trixie im Debian Tracker zum geprüften Stand noch als vulnerable markiert, obwohl dieselben Releases für CVE-2026-42530 nicht betroffen sind. Das ist genau der Punkt: Diese beiden CVEs dürfen nicht in einem pauschalen “NGINX gepatcht” verschwinden.

Schnelle Prüfung auf einem Host

Zuerst Version und Build prüfen:

nginx -v
nginx -V 2>&1
command -v nginx

Dann Paketstand prüfen. Debian und Ubuntu:

dpkg -l 'nginx*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
apt-cache policy nginx nginx-core nginx-full nginx-extras 2>/dev/null

RHEL, AlmaLinux, Rocky, Oracle, CloudLinux und Fedora:

rpm -q nginx nginx-core nginx-filesystem ea-nginx 2>/dev/null
dnf updateinfo info nginx 2>/dev/null || true
dnf module list nginx 2>/dev/null || true

SUSE und openSUSE:

zypper se -si 'nginx*'
zypper patches --cve=CVE-2026-42055 2>/dev/null || true
zypper patches --cve=CVE-2026-42530 2>/dev/null || true

Alpine:

apk version -v nginx
apk info -vv nginx

Für Container:

docker images --format '{{.Repository}}:{{.Tag}} {{.ID}}' | grep -i nginx
docker run --rm <image> nginx -v

Bei Kubernetes oder Ingress-Controllern musst du das konkrete Controller-Image prüfen:

kubectl get pods -A -o wide | grep -i nginx
kubectl get deploy -A -o yaml | grep -i 'image:.*nginx'

Konfiguration auf CVE-2026-42055 prüfen

nginx -T zeigt die komplette geladene Konfiguration. Auch hier gilt: Ausgabe kann interne Hostnamen, Pfade und Secrets in Snippets enthalten.

sudo nginx -T 2>/tmp/nginx-config.err \
  | grep -nE 'proxy_http_version[[:space:]]+2|grpc_pass|ignore_invalid_headers|large_client_header_buffers'

Verdächtig wird es, wenn alle drei Bedingungen zusammenkommen:

proxy_http_version 2 oder grpc_pass
ignore_invalid_headers off
large_client_header_buffers mit einem Buffer größer als 2m

Prüfe die final wirksame Konfiguration, nicht nur die Datei, die dir zuerst einfällt. include-Dateien, Panel-Snippets, Ingress-Templates und generierte vHosts können Werte überschreiben.

Wenn du keine dieser Direktiven nutzt, ist CVE-2026-42055 praktisch deutlich weniger relevant. Ein Paketupdate bleibt trotzdem sinnvoll, weil derselbe Release-Zweig weitere Fixes enthält.

Konfiguration auf CVE-2026-42530 prüfen

HTTP/3 erkennst du meist an quic:

sudo nginx -T 2>/tmp/nginx-config.err \
  | grep -nE 'listen .*quic|http3[[:space:]]+on|quic_retry|ssl_early_data'

Zusätzlich prüfen, ob UDP 443 offen ist:

ss -lunp | grep ':443'

Wenn NGINX 1.31.0 oder 1.31.1 läuft und listen ... quic aktiv ist, ist der Host im relevanten Bereich. Wenn NGINX aus Debian, Ubuntu, RHEL oder SUSE kommt und der Vendor CVE-2026-42530 als not affected führt, ist der verwundbare HTTP/3-Code dort normalerweise nicht vorhanden. Das gilt aber nicht automatisch für selbst gebaute oder containerisierte NGINX-Binaries.

Updates und Mitigation

Die saubere Lösung ist ein NGINX-Update aus dem richtigen Paketkanal:

sudo nginx -t
sudo systemctl reload nginx

Vor dem Reload muss der Paketstand stimmen. Danach prüfst du Version und Worker-Status erneut.

Für CVE-2026-42055 kannst du als Übergang die Konfiguration entschärfen:

ignore_invalid_headers on;

oder die Header-Buffers wieder in einen normalen Bereich bringen:

large_client_header_buffers 4 16k;

Wichtig: Das ist ein Beispiel für einen üblichen kleinen Wert, kein blindes Tuning-Rezept. Manche Setups haben große Header bewusst gesetzt, etwa wegen SSO, großen Cookies oder Legacy-Clients. Dann musst du prüfen, welche Clients wirklich betroffen wären. Die Vendor-Mitigation sagt technisch: maximal 2 MB. Betrieblich ist meistens deutlich weniger sinnvoll.

Wenn ein gRPC- oder HTTP/2-Upstream nur intern genutzt wird, aber NGINX am öffentlichen Internet steht, bleibt der Angriff trotzdem relevant: Der Angreifer spricht mit dem öffentlichen NGINX, nicht mit deinem Backend.

Für CVE-2026-42530 ist die schnelle Mitigation:

# Vorübergehend HTTP/3 entfernen
listen 443 ssl http2;
# listen 443 quic reuseport;
# http3 on;

Danach:

sudo nginx -t
sudo systemctl reload nginx

Wenn du HTTP/3 über Alt-Svc bewirbst, entferne oder ändere auch den Header. Sonst versuchen Clients weiter, HTTP/3 zu nutzen, obwohl du QUIC abgeschaltet hast.

# add_header Alt-Svc 'h3=":443"; ma=86400' always;

Was beim Patchen gern übersehen wird

Der erste Fehler ist, nur nginx -v zu prüfen. Bei Panel- und Container-Setups können mehrere NGINX-Binaries existieren. Entscheidend ist die Binary, die auf 80/443 oder UDP 443 wirklich Traffic annimmt.

Der zweite Fehler ist, CVE-2026-42530 zu überbewerten und CVE-2026-42055 zu übersehen. HTTP/3 ist sichtbar und modern, aber viele Distributionen sind dafür nicht betroffen. Die HTTP/2-/gRPC-Lücke betrifft dagegen ältere und konservativere Paketstände.

Der dritte Fehler ist, nur Defaults zu lesen. large_client_header_buffers wird oft in globalen Includes oder Panel-Templates gesetzt. Ein einzelner vHost kann die globale Risikolage ändern.

Der vierte Fehler ist ein Update ohne Image-Rollout. Bei Containern reicht ein neues Base-Image im Registry-Tag nicht. Die laufenden Pods oder Container müssen wirklich ersetzt werden.

Der fünfte Fehler ist fehlendes Monitoring nach dem Reload. Achte auf Worker-Crashes, 502-Spitzen, gRPC-Fehler und HTTP/3-Fallbacks.

Einordnung für produktive Systeme

Für klassische KMU- und Agenturserver ohne gRPC, ohne HTTP/2-Upstream-Proxying, ohne übergroße Header-Buffers und ohne HTTP/3 ist die Lage meist überschaubar. Trotzdem lohnt das Update, weil NGINX im Mai und Juni 2026 mehrere Speicherfehler gefixt hat.

Für API-Gateways, Kubernetes-Ingress, gRPC-Frontends, SSO-lastige Anwendungen, große Reverse-Proxies und CDN-nahe Setups ist CVE-2026-42055 deutlich relevanter. Dort werden Header-Limits eher angehoben, und gRPC ist kein Sonderfall.

Für experimentelle oder performanceorientierte Setups mit HTTP/3 ist CVE-2026-42530 klar: Wenn Mainline 1.31.0 oder 1.31.1 läuft, nicht diskutieren, sondern auf 1.31.2 gehen oder HTTP/3 aus.

Bei einem produktiven Kunden-Setup wäre die Reihenfolge:

Aktive NGINX-Binaries und Container-Images erfassen.
Paketstände gegen NGINX-, Vendor- und Panel-Tracker prüfen.
nginx -T auf grpc_pass, proxy_http_version 2, ignore_invalid_headers, large_client_header_buffers und quic prüfen.
Betroffene Systeme priorisieren: öffentliche API-Gateways, gRPC, HTTP/3, große Header zuerst.
Update oder temporäre Mitigation ausrollen.
nginx -t, Reload, Monitoring und synthetische Checks.
Nachkontrolle dokumentieren: Version, Paketquelle, Config-Entscheidung und Reload-Zeitpunkt.

Wenn du nicht sicher bist, ob deine Reverse-Proxies, Panels oder Ingress-Controller betroffen sind, ist ein kurzer Betriebs- und Security-Check sinnvoller als blindes Deaktivieren von HTTP/3 oder gRPC. Gerade bei API- und SSO-Setups kann eine falsche Header-Mitigation echte Produktion brechen.

Update-Log

2026-06-17: NGINX veröffentlichte 1.30.3 stable und 1.31.2 mainline. 1.30.3 fixt CVE-2026-42055 und CVE-2026-48142; 1.31.2 fixt zusätzlich CVE-2026-42530.
2026-06-17: F5 veröffentlichte die Advisories K000161584 für CVE-2026-42055 und K000161616 für CVE-2026-42530.
2026-06-18: The Hacker News berichtete über die beiden neuen NGINX-Open-Source-Lücken und die F5-Patches.
2026-06-19: CyStack veröffentlichte einen Research-Beitrag zu CVE-2026-42055 und dem HTTP/2-/gRPC-Upstream-Pfad.
2026-06-22: Debian und Alpine/OSV hatten sichtbare Tracker-Updates zu CVE-2026-42055. Debian stable blieb zum geprüften Stand für 42055 vulnerable, während 42530 als fixed/not affected geführt wurde.
2026-06-25: Ubuntu führte konkrete Fixversionen für CVE-2026-42055 in 26.04, 25.10, 24.04 und 22.04; CVE-2026-42530 blieb für Ubuntu-Pakete not affected.
2026-06-29: Artikel mit Red-Hat-, SUSE-, Amazon-Linux-, Alpine-, Debian- und Ubuntu-Ständen aktualisiert und die Mitigationen für ignore_invalid_headers, Header-Buffers und HTTP/3 ergänzt.