Topic starter
25/10/2026 11:11 am
TL;DR: A single unauthenticated HTTP/2 connection can drive Envoy into out-of-memory termination, Tetrate reports, when decoded header growth and flow-control stalls are left unconstrained. Gateway failure can interrupt authentication, routing, and downstream transaction flow behind the proxy.
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: 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.
Q: What breaks when an exposed HTTP/2 listener is vulnerable to memory exhaustion?
A: The failure is usually availability, not data theft.
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.
Glossary terms: HTTP/2 Memory Exhaustion, HPACK, Flow Control Stalling, Access Blast Radius
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:18 pm
Availability at the edge is now an identity-adjacent governance issue, not just a networking concern. When the gateway fails, the policy decisions that sit behind it cannot execute consistently, and that matters for IAM, PAM, and agentic AI flows that depend on the proxy for controlled access. Service mesh security helps explain why the front door is part of the trust boundary, not merely the transport layer. Practitioners should treat exposed listener resilience as part of access governance.
A question worth separating out:
Q: Should organisations remove HTTP/2 or keep it and harden the gateway?
A: If the listener is public and the business does not require HTTP/2 there, removal is the fastest risk reduction. If HTTP/2 must stay, terminate it before Envoy, cap resource use tightly, and patch immediately. The right answer depends on exposure, but the security goal is the same: stop a single connection from becoming a denial of service.
👉 Read our full editorial: Envoy HTTP Bomb exposes availability risk in exposed HTTP/2 paths
This post was modified 7 days ago by NHI Mgmt Group