HTTP Bomb (CVE-2026-47774): What Every Envoy User Needs to Know
The HTTP Bomb (CVE-2026-47774) is a high-severity HTTP/2 denial-of-service flaw in Envoy proxy. A single connection can exhaust 32 GB of memory in ~10 seconds. Here is how it works, who is affected, the patched Envoy versions, and how to mitigate it.
Tetrate Engineering Team 
The HTTP Bomb is a high-severity HTTP/2 denial-of-service vulnerability in Envoy proxy, tracked as CVE-2026-47774 (CVSS 7.5 / High). An unauthenticated attacker on a single residential internet connection can crash a vulnerable Envoy instance in about 10 seconds. If you run Envoy with an HTTP/2 endpoint exposed to untrusted clients, upgrade to a patched version (1.38.1, 1.37.3, 1.36.7, or 1.35.11) or disable HTTP/2 on exposed listeners.
Key facts
- What: HTTP/2 memory-exhaustion DoS in Envoy proxy, named “HTTP Bomb.”
- CVE: CVE-2026-47774 (Envoy); the broader disclosure also covers nginx, Apache httpd, Microsoft IIS, and Cloudflare Pingora, with CVE-2026-49975 assigned to the Apache variant.
- Severity: High — CVSS 7.5,
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. - Disclosed: June 2, 2026, by researchers at Calif using OpenAI’s Codex to chain the exploit. The official Envoy advisory was published June 3, 2026, crediting Ryoga Yamashita.
- Impact: ~5,700:1 amplification on Envoy — ~32 GB of memory consumed in ~10 seconds from one connection.
- Patched Envoy versions: 1.38.1, 1.37.3, 1.36.7, 1.35.11.
- Mitigation without upgrading: disable HTTP/2 on exposed listeners, or front Envoy with an HTTP/2-terminating proxy.
Tetrate Agent Router Enterprise provides continuous runtime governance for GenAI systems. Enforce policies, control costs, and maintain compliance at the infrastructure layer — without touching application code.
What is the HTTP Bomb vulnerability?
The HTTP Bomb (CVE-2026-47774) is not a single new flaw. It chains two long-known HTTP/2 behaviors into a memory-exhaustion attack at a rate the protocol’s designers never anticipated. It works in three stages:
- HPACK indexed reference bomb. HTTP/2’s HPACK compression (RFC 7541) lets both sides keep a dynamic table of recently seen headers. An attacker seeds the table with one header, then sends thousands of 1-byte references to it. Each byte on the wire costs Envoy a full in-memory header copy — roughly 5,700:1 amplification — because cookie header bytes were not fully accounted for during header size validation, and HPACK header block limits in oghttp2/quiche were enforced on encoded bytes without a corresponding limit on decoded size.
- HTTP/2 window stall (Slowloris variant). The attacker advertises a zero-byte flow-control window so Envoy can never finish its response and free memory, then drips 1-byte
WINDOW_UPDATEframes to keep the connection alive and the allocations pinned. - Cascade to OOM. Envoy accumulates memory faster than it can reclaim it. A single connection is enough to trigger out-of-memory termination of the process and a full denial of service.
The individual techniques are old — Cory Benfield coined “HPACK Bomb” in 2016 (CVE-2016-6581). What is new is the combination, and that OpenAI’s Codex was used to chain it — synthesizing an attack from decade-old documented techniques that humans had not assembled at this severity. Proof-of-concept code is public, so the barrier to exploitation is low.
How severe is it across web servers?
| Server | Amplification | Demo result |
|---|---|---|
| Envoy 1.37.2 | ~5,700:1 | ~32 GB in ~10s |
| Apache httpd 2.4.67 | ~4,000:1 | ~32 GB in ~18s |
| nginx 1.29.7 | ~70:1 | ~32 GB in ~45s |
| Microsoft IIS (Windows Server 2025) | ~68:1 | ~64 GB in ~45s |
Source: Calif initial disclosure, June 2, 2026. Envoy’s higher ratio stems from how it accounted for cookie-header bytes and HPACK-decoded size. A Shodan scan at time of disclosure identified 880,000+ public-facing servers running affected software with HTTP/2 enabled.
Who is affected?
Any Envoy proxy that exposes an unauthenticated HTTP/2 endpoint to clients is potentially vulnerable. Risk depends on topology:
| Scenario | Risk |
|---|---|
| Envoy gateway exposed to the internet or untrusted clients over HTTP/2 | High — patch now |
| Envoy behind an HTTP/2-terminating load balancer or CDN | Reduced — the front proxy may absorb the attack |
| Mesh sidecars requiring mutual TLS | Low — attackers need valid mTLS credentials first |
| HTTP/2 disabled on exposed listeners | Not vulnerable |
This reaches far beyond the edge: in a service mesh, any ingress gateway that does not require mutual TLS from downstream clients is an entry point. Because the result is OOM termination rather than graceful degradation, a successful attack is a hard outage until the process restarts — and for AI gateway workloads routing traffic to large language model backends, that can mean dropped transactions and incomplete tool-call sequences mid-flight.
Which Tetrate products are affected?
Every Tetrate product runs on Envoy and is affected. Patched releases are available now:
| Product | Patched version |
|---|---|
| Tetrate Istio Subscription | 1.30.0+1, 1.29.3+1, 1.28.7+1, 1.27.9+2 |
| Tetrate Service Bridge | 1.14.2 or 1.12.13 |
| Tetrate Envoy Gateway | 1.8.1 or 1.7.3 |
| Tetrate Agent Router Enterprise | Latest Tetrate Agent Router data plane |
How do you fix or mitigate the HTTP Bomb?
In order of preference:
- Upgrade Envoy to 1.38.1, 1.37.3, 1.36.7, or 1.35.11. Tetrate customers should upgrade to the patched release for their product (see table above). Prioritize public-facing gateways first.
- Disable HTTP/2 on any listener reachable by unauthenticated clients. This removes the attack surface at the cost of HTTP/2 performance.
- Front Envoy with an HTTP/2-terminating proxy that enforces a hard per-request header-count cap.
- Cap per-worker memory via cgroups or container limits, so a bombed worker is OOM-killed and respawned cleanly rather than dragging the host into swap.
Tetrate customers who cannot upgrade immediately can also pin the Envoy image to a patched version using the Envoy Gateway customization API, or — for Tetrate Service Bridge — patch running gateway and mesh deployments in place per the product advisory.
How did Tetrate respond?
Tetrate was founded by core Envoy and Istio contributors and remains a top upstream maintainer of both projects, including as a founding maintainer of the Envoy AI Gateway. That position means we are part of the fix, not just a downstream packager.
Within days of disclosure, Tetrate shipped patched builds across all product lines and published product-specific advisories — for Tetrate Service Bridge, Tetrate Istio Subscription, Tetrate Envoy Gateway, and Tetrate Agent Router Enterprise — each with concrete upgrade paths, in-place patch procedures, and mitigations rather than a generic pointer to the CVE. Contact Tetrate support for upgrade assistance.
Frequently asked questions
Is CVE-2026-47774 the same as CVE-2026-49975?
They describe the same HTTP Bomb class of attack but are distinct identifiers. CVE-2026-47774 tracks the Envoy-specific issue (advisory GHSA-22m2-hvr2-xqc8); CVE-2026-49975 was assigned to the Apache httpd variant.
Which Envoy versions are patched?
1.38.1, 1.37.3, 1.36.7, and 1.35.11. All versions below 1.35.11 remain unpatched.
What is the CVSS score?
CVSS 7.5 (High), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The score reflects network-accessible, no-authentication-required, high availability impact with no confidentiality or integrity exposure.
Can I stay safe without upgrading?
Yes, temporarily. Disable HTTP/2 on exposed listeners, front Envoy with an HTTP/2-terminating proxy that caps header counts, or cap per-worker memory. Upgrading remains the durable fix.
Are mutual-TLS mesh sidecars vulnerable?
The risk is low. An attacker must present valid mTLS credentials before they can reach the vulnerable HTTP/2 path, which raises the bar significantly compared to public-facing gateways.
Tetrate Engineering Team 
