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.
At a glance
What this is: This is a high-severity HTTP/2 memory-exhaustion flaw in Envoy that can crash a vulnerable instance from a single unauthenticated connection.
Why it matters: It matters because gateway availability, not just authentication, becomes the control problem when edge traffic can force resource exhaustion before policy enforcement can help.
By the numbers:
- A single connection can exhaust about 32 GB of memory in roughly 10 seconds on Envoy.
Context
HTTP/2 can compress repeated headers efficiently, but that efficiency becomes a liability when decoded size is not constrained as tightly as encoded size. In Envoy, the flaw is an availability issue at the edge, where a small amount of inbound traffic can trigger disproportionate memory growth and terminate the proxy.
For identity and access practitioners, the significance is indirect but real: when a gateway dies, authentication, authorisation, and policy enforcement on that path fail with it. In service-mesh and AI-gateway deployments, this turns traffic handling into a resilience and blast-radius problem, not just a transport issue.
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. A vulnerable listener can consume memory faster than it can free it, crash the proxy process, and interrupt every service that depends on that gateway. In practice, the broken control is request handling at the trust boundary, so the outage can look like a network issue even though the root cause is protocol abuse.
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. If decoded headers are not governed as carefully as encoded bytes, an attacker can multiply resource use with repeated references and stalled responses. The outage risk grows when the listener is public, because the attacker needs no credentials and can keep the connection alive cheaply.
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. If a single connection can pin resources long enough to threaten process health, the control boundary is too weak for the traffic profile.
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.
Technical breakdown
How HPACK indexing turns a small request into large memory pressure
HTTP/2 uses HPACK to compress repeated headers by storing them in a dynamic table and then referencing them by index. The attack seeds that table once, then sends many tiny references that cause Envoy to materialise full in-memory header copies. The key failure is not compression itself, but the mismatch between encoded-byte limits and decoded memory cost, which allows one connection to multiply resource usage far beyond what the wire traffic suggests.
Practical implication: Treat decoded header growth as the real control surface and enforce limits that reflect in-memory cost, not just packet size.
Why flow-control stalls can pin memory long enough to break the proxy
The second stage abuses HTTP/2 flow control. By advertising a zero-byte window and then trickling small WINDOW_UPDATE frames, the attacker keeps the connection alive while preventing Envoy from completing the response and releasing allocations. That creates a Slowloris-like effect inside the HTTP/2 state machine, where the proxy remains busy and memory remains pinned. The result is not gradual degradation but accelerating pressure toward out-of-memory termination, especially when the listener is exposed directly to untrusted clients.
Practical implication: Cap per-connection and per-worker resources so stalled HTTP/2 sessions cannot hold memory indefinitely.
Why a single edge listener can become a service-wide outage point
In gateway architectures, the listener is often the first shared chokepoint for many upstream services. When that component OOMs, the failure propagates beyond one request path and can interrupt downstream tool calls, API sessions, and other in-flight transactions. The practical issue is control-plane and data-plane coupling: a traffic-management component that is supposed to absorb load can itself become the outage trigger. That makes placement, fronting, and protocol exposure decisions part of the security model, not just the network design. See the Service Mesh Security Guide.
Practical implication: Place untrusted HTTP/2 traffic behind stronger front-end controls or remove the protocol from exposed listeners where business continuity is critical.
Threat narrative
Attacker objective: The attacker wants to force a vulnerable Envoy gateway into process failure and interrupt availability for the services behind it.
- Entry occurs through a public HTTP/2 listener on a vulnerable Envoy instance, where the attacker needs no credentials and can connect from a residential line.
- Credential harvest is not required, because the abuse path relies on protocol behaviour and state management rather than account compromise.
- Escalation happens when repeated header references and flow-control stalling force the proxy to retain memory far beyond normal request cost.
- Impact is out-of-memory termination of the Envoy process, producing a hard denial of service for the traffic path it fronts.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
This vulnerability illustrates header-size blind spots, a control gap that conventional request filtering does not close. The flaw arises because encoded bytes and decoded memory cost are not governed by the same checks, which creates a mismatch attackers can exploit. That is a named failure mode: decoded-cost undercounting. Security teams should align policy with resource consumption, especially where protocol compression changes the true cost of a request.
HTTP/2 exposure without front-end containment creates a blast-radius problem that looks like an application bug but behaves like an infrastructure outage. The article shows that a single listener can become the failure domain for an entire gateway tier. For teams operating service meshes or AI gateways, the question is not whether the protocol is efficient, but whether the runtime can survive hostile efficiency. Practitioners should reduce the number of untrusted paths that can reach the vulnerable data plane.
The right control mindset is resilience-first, because availability failures propagate into authentication and orchestration layers very quickly. In gateway-heavy environments, a dead proxy can interrupt session establishment, token exchange, tool routing, and downstream transaction completion. That makes rate limiting, protocol termination, and exposure reduction part of identity security architecture, not just infrastructure hygiene. Practitioners should model proxy failure as a governance event, not an isolated outage.
What this signals
Decoded-cost governance: protocols that compress traffic can still expand into dangerous memory use after parsing, so the operational control has to track what the proxy actually allocates, not what the network receives. That matters for gateways, meshes, and AI routing layers alike, because the same blind spot can turn efficient traffic handling into a denial-of-service path.
Gateway teams should expect availability failures to be treated more like trust-boundary incidents than simple uptime events. Where shared ingress, service mesh, and AI gateway layers converge, resilience controls such as protocol termination, resource ceilings, and exposure reduction become part of identity-adjacent governance rather than post-incident housekeeping.
For practitioners
- 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.
- Cap per-worker memory and isolate failure Use container or cgroup limits so a bombed worker is killed and restarted cleanly instead of forcing host-wide swap pressure.
Key takeaways
- 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.
- The vulnerability matters because gateway failure breaks more than transport, it can interrupt authentication, routing, and downstream transaction flow behind the proxy.
- Practitioners should prioritise patching, remove HTTP/2 where it is not needed, and place hard limits on the memory cost of exposed listeners.
Related NHI Mgmt Group resources: Zero-Day and Exploited Vulnerabilities Guide · SSRF Prevention Guide · Service Mesh Security Guide · Vulnerability Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0040 — Initial Access; Impact | The article describes unauthenticated network entry followed by process failure and service outage. |
| Recommendation — Map the attack path to TA0001 and TA0040, then hunt for exposed listeners that can be forced into OOM impact. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Untrusted listeners should not grant arbitrary access to resource-heavy request paths. |
| Recommendation — Restrict exposed HTTP/2 listeners so only intended clients can reach high-cost request processing paths. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | The flaw is exploitable on reachable services and benefits from exposure reduction and monitoring. |
| Recommendation — Monitor externally reachable gateways and isolate or remove high-risk listener exposure. | ||
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | The primary issue is service availability under a protocol-based resource exhaustion attack. |
| Recommendation — Apply SC-5 to cap resource consumption and reduce the impact of request-amplification attacks. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | The attack turns a small request into excessive memory consumption on a network-facing service interface. |
| Recommendation — Treat resource amplification as an API-layer abuse case and enforce hard consumption limits. | ||
Key terms
- HTTP/2 Memory Exhaustion: A denial-of-service condition where an attacker forces an HTTP/2 endpoint to allocate disproportionate memory relative to the request size. The risk often emerges when compression, header parsing, and flow control are not constrained against decoded resource cost.
- HPACK: HPACK is the header-compression scheme used by HTTP/2 to reduce repeated header overhead. It can also create attack surface when compressed references expand into large in-memory structures and the implementation does not enforce decoded-size limits tightly enough.
- Flow Control Stalling: Flow control stalling is the deliberate slowing or blocking of protocol progress so the server keeps state and memory allocated longer than normal. Attackers use it to pin resources and prevent cleanup, turning efficient session handling into an availability risk.
- Access Blast Radius: Access blast radius is the amount of damage possible if an identity, credential, or permission set is misused or compromised. It is shaped by privilege scope, resource reach, lateral movement paths, and data sensitivity, and it is reduced by tight authorization and segmentation.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. The course helps practitioners connect access governance, machine identity risk, and runtime control to the broader security programme.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org