HTTP/2 Bomb: A New Denial-of-Service Technique Targeting Web Servers

A newly discovered denial-of-service (DoS) technique dubbed HTTP/2 Bomb has drawn significant attention across the security industry due to its ability to exhaust server memory and render web services unavailable within seconds.

The attack was publicly disclosed in June 2026 by California-based security research company Calif. According to the researchers, the technique was discovered with assistance from OpenAI Codex, which identified a previously overlooked attack chain by combining several known HTTP/2 weaknesses into a single highly effective exploit.

Key Takeaways

• HTTP/2 Bomb combines HPACK amplification and flow-control abuse.
• Low attacker bandwidth can trigger significant memory exhaustion.
• Default configurations of several major web server technologies were reportedly affected.
• Traditional volumetric DDoS protections may not detect the attack because it targets server resource allocation rather than network capacity.
• Organizations should validate resilience through testing rather than relying solely on patch status.

HTTP/2 Bomb Attack Introduction

Unlike many recently disclosed vulnerabilities, HTTP/2 Bomb is not based on a newly discovered protocol flaw. Instead, it chains together multiple previously known denial-of-service techniques that individually were considered either low risk or already mitigated in many environments. When combined, however, they create a highly efficient attack capable of consuming large amounts of memory using very little attacker bandwidth.

At a high level, the attack leverages two characteristics of HTTP/2:

1. Header Compression Amplification (HPACK Compression Bomb)
   HTTP/2 uses a header compression mechanism called HPACK to reduce bandwidth consumption. By carefully crafting requests, an attacker can cause a server to allocate significantly more memory than the amount of data transmitted over the network.
2. Slowloris-Style Resource Retention
   After forcing the server to allocate memory, the attacker prevents those resources from being released by abusing HTTP/2 flow-control mechanisms, causing memory consumption to continuously increase.

The result is a highly asymmetric attack where a relatively small amount of traffic can consume gigabytes of server memory and cause service degradation or complete unavailability. Researchers demonstrated scenarios where a single client was capable of consuming tens of gigabytes of memory within seconds.

The disclosure is particularly noteworthy because it continues a trend of HTTP/2-based denial-of-service attacks observed over recent years, including:

• HTTP/2 Rapid Reset (CVE-2023-44487)
• HTTP/2 Continuation Flood
• MadeYouReset (2025)
• Various HPACK and flow-control abuse techniques

These incidents demonstrate that protocol-level complexity continues to create opportunities for attackers to develop increasingly efficient resource-exhaustion attacks.

Technical Details

How the Attack Works

HTTP/2 introduces several features designed to improve performance, including:

• Multiplexed streams
• Header compression (HPACK)
• Flow control
• Stream prioritization

HTTP/2 Bomb abuses two of these features simultaneously.

Stage 1 – HPACK Amplification

HTTP/2 references previously stored headers using indexes.

This normally reduces network overhead because repeated headers can be represented by only a few bytes.

However, under certain conditions, a very small compressed payload can force the server to reconstruct and allocate a much larger set of headers in memory. Researchers reported amplification ratios ranging from dozens to thousands of times greater than the original request size.

Stage 2 – Memory Retention

Normally, memory allocated for processing a request is released after the request completes.

The second stage of the attack prevents this cleanup process by abusing HTTP/2 flow-control behavior in a manner similar to the classic Slowloris attack.

As a result, memory allocations remain active for extended periods, allowing an attacker to continuously accumulate memory usage until the server becomes unstable or unavailable.

Importantly, the attack does not require a large botnet. Researchers reported that attacks can be launched from a standard residential Internet connection and still achieve significant impact against vulnerable deployments, highlighting the highly asymmetric nature of the technique and the relatively low barrier to entry for potential attackers.

Potentially Affected Technologies

According to the public disclosure, default HTTP/2 configurations of the following technologies were observed to be vulnerable during testing:

• NGINX
• Apache HTTP Server (httpd)
• Microsoft IIS
• Envoy Proxy
• Cloudflare Pingora

The researchers estimate, based on Shodan Search, that more than 880,000 Internet-facing websites may potentially be exposed.

Are Patched Versions Available?

At the time of writing, the situation continues to evolve.

One component of the attack chain involving Apache HTTP Server was reportedly addressed previously in Apache HTTP Server 2.4.64 under CVE-2025-53020. However, organizations should not assume they are protected solely because one individual issue has been patched. The HTTP/2 Bomb technique specifically relies on chaining multiple behaviors together.

What Should Organizations Do Now?

Although exploitation activity has not yet reached the scale seen during the HTTP/2 Rapid Reset attacks, organizations should treat this disclosure as a reminder to review their HTTP/2 exposure and resilience posture.

We recommend the following actions:

1. Inventory Internet-Facing HTTP/2 Services

Identify Web servers that expose HTTP/2 to external clients from the internet.

2. Verify Software Versions

Ensure all exposed infrastructure components are running vendor-supported versions and that available security updates have been applied.

3. Validate DDoS Protection Coverage

Confirm that all public-facing web services are protected/utilizing Cloud Reverse Proxies such as CDNs and WAFs where appropriate.

4. Test Detection and Response Capabilities

Organizations should verify that Monitoring systems can detect memory exhaustion conditions and web service availability on the application layer (HTTP Responses).

5. Review Exposure of Non-Essential Services

Any web service that does not require direct Internet accessibility should be restricted through network segmentation, VPN access, allowlists, or other access-control mechanisms.

What Does This Vulnerability Teach Us?

HTTP/2 Bomb highlights several important lessons for modern security teams.

Complexity Creates Risk

Many recent denial-of-service vulnerabilities are not caused by implementation mistakes alone but by the complexity of modern protocols themselves. As protocols evolve to improve performance and efficiency, attackers gain additional opportunities to combine legitimate features in unintended ways.

AI Is Accelerating Security Research

Perhaps the most interesting aspect of this disclosure is that researchers reported the attack chain was identified with assistance from OpenAI Codex.

While security researchers have historically discovered vulnerabilities through manual analysis, AI systems are increasingly capable of identifying relationships between previously known weaknesses and uncovering attack paths that human researchers may overlook.

This trend is likely to accelerate both defensive research and offensive capability development.

Regular Validation of Defenses Cannot be Overlooked

Perhaps the most important lesson is that resilience cannot be inferred from architecture diagrams, vendor claims, or patch status alone. Protocol-level attacks such as HTTP/2 Bomb demonstrate why organizations should regularly validate their defenses under realistic attack conditions to understand how applications, proxies, load balancers, and security controls behave when resource exhaustion occurs. Learn more about our DDoS testing validation.