HTTP/2 Bomb: How Default Configurations Open a New DoS Vector

A newly disclosed Denial-of-Service (DoS) technique dubbed HTTP/2 Bomb can crash or stall servers that run default HTTP/2 configurations across several widely deployed stacks. The technique chains two behaviors that are individually familiar to defenders: header-related amplification and Slowloris-style connection holding. Combined, they can exhaust memory.

Proof-of-Concept (PoC) exploits are available and fixes are uneven across vendors, which makes this relevant for teams that operate internet-facing HTTP/2 endpoints. This post explains what HTTP/2 Bomb is, who is affected, how the chain works at a high level, what we know about exploitation, and what defenders should do now.

What Is HTTP/2 Bomb?

HTTP/2 Bomb is a remote Denial-of-Service (DoS) attack chain that targets how some HTTP/2 implementations allocate memory during header processing and how they release that memory when a connection stalls.

The amplification does not rely on exceeding common “decoded header size” limits. Instead, it drives large per-header or per-entry bookkeeping allocations from small on-the-wire inputs, allowing the decoded content to remain small while server-side memory usage grows.

Which Products and Deployments Are Affected?

Reports attribute impact, in default HTTP/2 configurations, to a set of major servers and proxies, including:

• nginx
• Apache httpd (mod_http2)
• Microsoft IIS
• Envoy
• Cloudflare Pingora

Exposure estimates suggest a large potential footprint across HTTP/2-enabled sites, although real-world exploitability will depend on whether the vulnerable component is directly reachable or shielded behind a CDN or front proxy that terminates HTTP/2.

How Does Exploitation Work in Practice?

HTTP/2 Bomb is best understood as two stages that reinforce each other.

1. How does the header “amplification” stage inflate memory?

The attacker crafts HTTP/2 header representations that are tiny on the wire but trigger the server to allocate and track a large number of header-related structures. In simplified terms, the attacker aims for a ratio where “very little input” forces “a lot of allocation,” repeated many times within a request or across streams.

This matters operationally because many environments defend against classic HPACK-based issues by limiting decoded header size, and this technique shifts pressure to implementation bookkeeping costs that may not be governed by those decoded-size caps.

2. How does the flow-control “hold” stage keep memory pinned?

After the server allocates memory while processing the crafted headers, the attacker uses an HTTP/2 Slowloris-style technique to prevent that memory from being freed promptly.

The reported method is to abuse HTTP/2 flow control by advertising a 0-byte window so the server cannot send responses and clean up state normally. Periodic traffic can keep the connection alive long enough for memory use to climb until the service becomes unavailable.

How Fast Can It Take Down a Server?

Research suggests the impact can be remarkably fast: a 100Mbps home connection can disable a vulnerable server in seconds. Specifically, one client can consume 32GB of memory on Apache httpd and Envoy in about 20 seconds.

Treat these as reported performance claims rather than universally reproducible benchmarks. Real impact will vary based on worker limits, per-connection memory behavior, HTTP/2 settings, upstream timeouts, and whether a reverse proxy enforces stricter constraints before traffic reaches the affected component.

Is There Evidence of Active Exploitation?

Current reporting focuses on disclosure, PoC availability, and patch status, without confirmed broad telemetry showing large-scale in-the-wild exploitation.

Given the availability of PoC scripts on GitHub, defenders should still assume opportunistic scanning is occurring, particularly against internet-facing HTTP/2 services running default settings without front-door header-limit enforcement.

What Should Defenders Do Now?

Prioritize actions based on whether your HTTP/2 endpoints are directly reachable from untrusted networks, and whether you can patch versus needing compensating controls.

Which patches or upgrades are available?

• nginx: reporting indicates a fix in 1.29.8, including a max_headers directive to limit the number of request headers per request.
• Apache httpd: reporting indicates a fix in mod_http2 2.0.41, tracked as CVE-2026-49975.

• Envoy: patches released as of June 3, 2026 – see the security advisory. (Validation is ongoing)

For IIS and Pingora, no patch was available at the time of disclosure (June 2-3, 2026). Recommended mitigations remain disabling HTTP/2 or placing protective controls in front of the affected service.

What compensating controls reduce risk if you cannot patch?

If you cannot upgrade quickly, focus on controls that break the two-stage chain, either by preventing allocation spikes or by preventing long-lived stalled connections:

• Disable HTTP/2 on internet-facing services where the performance tradeoff is acceptable.
• Front the service with a reverse proxy or gateway that enforces hard limits, especially:
• Header count limits (not only decoded header size)
• Per-connection and per-stream resource ceilings where supported
• Connection concurrency limits
• Timeouts that prevent long-lived, low-throughput holds

What monitoring signals are worth adding right away?

Even without vendor-specific detection guidance, several practical signals can help you spot early stress and triage faster:

• Surges in HTTP/2 connections paired with rising per-worker memory
• Requests or streams with unusually high header counts
• Connections that remain open with minimal throughput but steadily increasing memory consumption

If your proxies expose HTTP/2 metrics, consider alerting on abnormal patterns in stream resets, header-related limit violations, and long-lived connections that do not progress.

By the time a vulnerability like HTTP/2 Bomb makes it into your feed, PoC code is already on GitHub and opportunistic scanning has likely begun. The defenders who respond fastest aren’t reading faster, but have better signals.

SOCRadar’s Cyber Threat Intelligence gives your team continuous visibility into the threat landscape: newly disclosed CVEs and their real-world severity, exploit code surfacing across public repositories and Dark Web forums, active exploitation campaigns targeting web infrastructure, and vendor patch timelines tracked automatically across affected stacks.

Conclusion

HTTP/2 Bomb works because protocol efficiency features can become attack surfaces. Flow control and header compression were built for performance – here, they’re chained together to exhaust memory with a single consumer connection. No botnet, no volume, no sophistication required.

The patch gap is the real operational headache. nginx and Apache are covered; Envoy is in validation; IIS and Pingora had no patch at disclosure. Your exposure depends entirely on which component in your stack terminates HTTP/2.

Before moving on, make sure you can answer these:

• Where does HTTP/2 terminate – CDN, reverse proxy, or origin?
• Do your header defenses cap count, or just decoded size?
• What breaks if you disable HTTP/2 on a critical service tomorrow?

Patch where fixes exist. Enforce strict header-count and connection-hold limits where they don’t.