GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy: unauthenticated HTTP/2 cookie and HPACK decoded-size gap drives the proxy to OOM

CVSS 7.5CVE-2026-47774Container, Kubernetes & orchestrationcurated

Impact

An unauthenticated client speaking HTTP/2 to any Envoy listener can make the process allocate very large decoded header blocks while staying under the configured request header size limit, because cookie bytes are not fully counted and the oghttp2/quiche HPACK limit applies only to encoded bytes. The proxy is killed by the OOM reaper and traffic through it stops. On a GPU fleet this is the ingress and service-mesh data plane: an Envoy that dies takes inference endpoints, model gateways and mesh-internal calls with it, and in a sidecar deployment the blast radius is every pod sharing that sidecar. Red Hat ships the same fix for OpenShift Service Mesh 2.6 and 3.0 through 3.3.

Who can reach it

Anyone who can open an HTTP/2 connection to an Envoy downstream listener - typically the public internet or any tenant network that reaches the ingress. No authentication required.

What to do

Upgrade Envoy to 1.35.11, 1.36.7, 1.37.3 or 1.38.1, or apply the OpenShift Service Mesh errata (RHSA-2026:26210/26222/26231) and restart the proxies. Sidecar fleets need a rolling pod restart so each injected Envoy picks up the new image; no node reboot or GPU drain is needed. No complete workaround exists; interim mitigations named by the advisory are disabling downstream HTTP/2 where feasible, enforcing stricter header and cookie limits upstream of Envoy, and watching Envoy memory growth.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.