Topic starter
25/10/2026 11:11 am
TL;DR: CVE-2026-47774, the Envoy HTTP Bomb, lets an unauthenticated attacker exhaust roughly 32 GB of memory in about 10 seconds over a single HTTP/2 connection, creating a high-severity denial-of-service condition, according to Tetrate. This is a protocol-abuse problem, not a patch-speed problem: exposed listeners need hard limits, fronting controls, or HTTP/2 removal.
Editorial analysis by NHI Mgmt Group, based on content published by Tetrate: “HTTP Bomb (CVE-2026-47774): What Every Envoy User Needs to Know”.
By the numbers:
- A single connection can exhaust about 32 GB of memory in roughly 10 seconds on Envoy.
Key questions
Q: What breaks when an exposed HTTP/2 listener is vulnerable to memory exhaustion?
A: The failure is usually availability, not data theft.
Q: Why does a small HTTP/2 request sometimes create a large outage risk?
A: Because compression and flow control can decouple wire size from in-memory cost.
Q: How do security teams know whether HTTP/2 exposure is becoming a stability problem?
A: Look for listeners that accept untrusted traffic, gateways that retain memory under slow or repetitive request patterns, and deployments that do not enforce hard limits on decoded header growth.
Practitioner guidance
- Upgrade exposed Envoy instances first Move public-facing gateways to patched versions 1.38.1, 1.37.3, 1.36.7, or 1.35.11 before working on less exposed deployments.
- Disable HTTP/2 on untrusted listeners Remove the vulnerable attack surface on any endpoint reachable by unauthenticated clients when HTTP/2 is not required.
- Front Envoy with a terminating proxy Terminate HTTP/2 upstream of Envoy and enforce hard per-request header-count limits so decoded header growth cannot pin memory.
Bottom line: A single unauthenticated HTTP/2 connection can drive Envoy into out-of-memory termination when decoded header growth and flow-control stalls are not constrained.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →