When AI starts combining old CVEs into new attack techniques
Overview
A regular laptop with a 100 Mbps Internet connection can cause a web server with 32 GB of RAM to run out of resources in just a few seconds. It may sound like a large-scale DDoS attack, but in reality the attacker only needs to maintain a small number of specially crafted HTTP/2 connections.
That is exactly what the new technique called HTTP/2 Bomb has proven. Without exploiting a complex zero-day, bypassing authentication mechanisms, or using massive botnet infrastructure, HTTP/2 Bomb leverages perfectly valid features of the HTTP/2 protocol to force servers to continuously allocate and retain large amounts of memory. As a result, popular platforms such as Apache httpd, NGINX, Microsoft IIS, and Envoy can experience severe performance degradation or service outages at very short notice.
What makes the information security community pay special attention is not only the level of impact of the vulnerability but also how it was discovered. According to Calif researchers, this technique was discovered with the help of AI by combining many mechanisms and vulnerabilities that have been known for many years into a complete attack chain. HTTP/2 Bomb shows that even seemingly innocuous features of a popular protocol can become dangerous weapons when combined properly.
Technical context
The HTTP/2 Bomb attack was discovered by security company Calif using the OpenAI Codex tool to serialize two old attack techniques. The vulnerability has been assigned the following identifiers:
CVE-2026-49975 (Apache httpd mod_http2): CVSS v3 score reached 7.5 (High). Affects mod_http2 on Apache httpd versions 2.4.17 to 2.4.67.
CVE-2026-47774 (Envoy): CVSS v3 score reaches 7.5 (High). Affects the downstream request processing mechanism.
CVE-2026-49160 (Microsoft IIS): CVSS v3 score is 7.8 (High). Patched by Microsoft in the June 2026 update.
NGINX: Does not have a native CVE code but is affected in all versions before 1.29.8.
Related CWE: CWE-400 (Uncontrolled Resource Consumption) - System resource depletion beyond control.
Attackers use network vectors to send malicious HTTP/2 frames over HTTPS port (usually port 443). The attack requires no pre-auth and no interaction from the end user.
Mining mechanism
To understand the HTTP/2 Bomb, we need to analyze two core components of the HTTP/2 protocol: HPACK compression and flow control.
HPACK (RFC 7541): Is a stateful header compression mechanism. Both the server and client maintain a dynamic table that stores recently seen headers. The client can insert a header into this table once, then simply reference it by index (usually only 1 byte) in subsequent requests.
Flow Control (RFC 9113): Supports data flow control on each stream. The server must not send data that exceeds the window size advertised by the client until it receives the WINDOW_UPDATE frame. An attacker can take advantage of this to keep the response connection from the server always in a waiting state.
Difference between traditional HPACK Bomb and HTTP/2 Bomb
In a classic HPACK Bomb attack (like CVE-2016-6581), the attacker injects a very large header value into a dynamic table and references it continuously. Modern servers prevent this by limiting the total maximum decompressed header field size (decoded header size).
The HTTP/2 Bomb variant goes in the opposite direction:
The attacker sends nearly empty headers to bypass decompression size filters.
The amplification does not come from the data content, but from the bookkeeping overhead that the server must allocate to each entry created. One byte transmitted on the bus can correspond to thousands of bytes allocated in server RAM.
To keep these resources from being released, the attacker advertises a zero-byte flow-control window. The server cannot complete the request and is forced to keep the allocated memory areas in RAM. At the same time, the attacker periodically sends 1-byte WINDOW_UPDATE frames to reset the connection timeout..
Bypass via Cookie Crumbs mechanism
For servers that limit the number of header fields (like Apache and Envoy), attackers use the Cookie Crumbs technique. According to the RFC 9113 §8.2.3 specification, the Cookie header is allowed to be separated into many small fields on different streams. Because these servers do not count these crumbs toward the maximum header limit, an attacker can insert tens of thousands of cookie crumbs into memory.
Envoy: Join all crumbs into a common buffer. A 4KB cookie referenced 32,000 times will produce an RSS ratio of ~3,800:1 to ~5,700:1 due to the allocation overhead of the memory allocator.
Apache httpd: Mod_http2's design rebuilds the entire aggregate cookie chain every time a crumb is received, while retaining the old copy throughout the life of the stream. This design causes even an empty cookie to produce a resource amplification ratio of ~4,000:1.
| Server | Memory gain ratio | Actual test results |
|---|---|---|
| Envoy 1.37.2 | ~5,700:1 | Consumes ~32 GB RAM in ~10 seconds |
| Apache httpd 2.4.67 | ~4,000:1 | Consumes ~32 GB RAM in ~18 seconds |
| nginx 1.29.7 | ~70:1 | Consumes ~32 GB RAM in ~45 seconds |
| Microsoft IIS (Windows Server 2025) | ~68:1 | Consumes ~64 GB RAM in ~45 seconds |
Actual PoC code
publications/MADBugs/http2-bomb at main · califio/publications
Detailed mining process
Step 1: Establish TCP Connection & HTTP/2 Negotiation (Connection & ALPN Negotiation) The attacker initiates a regular TCP connection to the server's HTTPS port (443) and negotiates the HTTP/2 protocol via ALPN (Application-Layer Protocol Negotiation). After a successful TLS handshake, the HPACK dynamic compression table is set to an empty state on both ends of the connection.
Step 2: Load bait data into the dynamic table (Dynamic Table Seeding) The attacker sends the first request containing large Cookie or Custom Header values (for example, 4KB long cookie strings or special format strings) to bait data into the server's HPACK dynamic table. At this time, the server allocates memory accordingly to store these Name-Value pairs.
Step 3: Sending amplified compressed index references (Indexed Reference Bombing) After the decoy data is in the dynamic table, the attacker continuously sends subsequent frame headers containing thousands of index references pointing to the stored decoy element.
On wire format, each reference only takes 1 byte.
However, when decompressing, the server is forced to allocate memory resources for internal management mechanisms (bookkeeping) around each entry (from 70 bytes to 4,000 bytes depending on the structure of the web server). Sending fragmented cookie crumbs helps bypass header field count limit filters.
Step 4: Freeze the response window (Flow-Control Window Stall) Before the server completes processing and releases resources, the attacker sends a settings configuration or zero-byte flow-control window advertisement flow control frame. The server realizes that the client's receive buffer is full, so it stops the data response stream (stalled) but must still keep the entire RAM memory allocated in Step 3.
Step 5: Maintain memory pinning state (Session Pinning / Heartbeat Stall) To prevent the server from closing the connection due to inactivity timeout, the attacker continuously "trickles" 1-byte WINDOW_UPDATE frames or small ping frames to reset the socket timeout counters. The server's allocated memory is persistently pinned in RAM and cannot be freed.
Step 6: Resource Exhaustion (Memory Exhaustion & DoS) By running multiple streams as above in parallel in the same connection or on multiple connections simultaneously from a small bandwidth connection, the system's RAM resources are quickly exhausted, pushing the server into Swap state or being OOM-killed by the operating system.
Record actual exploitation
A special feature of HTTP/2 Bomb is the use of artificial intelligence models (OpenAI Codex) to combine security error design patterns that have been around for a long time.
In April 2026, a research team in California led by Quang Luong reported the vulnerability to NGINX, followed by Apache httpd on May 27, 2026. The vulnerability was promptly patched by the developers.
To date, there have been no confirmed reports of this vulnerability being exploited in the wild by APT groups before the time of publication. However, because the PoC exploit code has been made public and the commits on NGINX/Apache open source repositories clearly show the nature of the error, the risk of weaponizing this vulnerability by attack groups is extremely high.
MITRE ATT&CK Mapping
Below is a diagram mapping the attack behavior of HTTP/2 Bomb to the MITER ATT&CK matrix:
| Tactic | Technique | Describe |
|---|---|---|
| Impact (TA0040) | T1499 - Endpoint Denial of Service | Paralyzing the server system providing public services. |
| Impact (TA0040) | T1499.003 - Application Exhaustion Flood | Using valid but malicious HTTP/2 requests to exhaust RAM resources. |
Detection and Response
Detection logic (SIEM/IDS)
To detect an HTTP/2 Bomb attack, the SOC team needs to monitor for the following unusual signs:
Monitor long-term HTTP/2 connections with extremely low data transfer bandwidth (Slowloris-style).
A spike in minimum size (1 byte) WINDOW_UPDATE frames on a single connection.
An unusually large number of fragmented cookie headers (crumbs) per stream.
The Splunk query below helps identify suspicious HTTP/2 traffic based on cookie fragmentation signatures:
Incident Response Process (Incident Response)
If the monitoring system warns that the Web Server's RAM resources are continuously depleted:
Isolate the source of the attack: Block the source IP from sending large amounts of HTTP/2 requests through the WAF or border firewall.
Emergency resource limit: Configure cgroups or ulimit on the server to limit the maximum amount of RAM per worker process, preventing one worker from being bombed and bringing down the entire operating system into swap state.
Temporary switch: If you cannot update the software, redirect the server configuration to turn off the HTTP/2 protocol, only accepting HTTP/1.1 connections.
Expert opinion
Our analysis team found that protocol specifications are often the source of serious logic vulnerabilities. RFC 7541, the HPACK specification, was carefully designed to limit dynamic tables to avoid memory exhaustion, but protocol designers neglected the overhead of managing the data structures that arise around these entries.
Omitting the memory retention time factor (connection duration) is also a major design weakness. A small compression amplifier (like NGINX's 70:1) is harmless if memory is freed as soon as the request completes. But if the protocol allows an attacker to maintain a nearly free connection using Window Stall, that amount of memory will be tied up indefinitely, creating a perfect denial of service attack.
In the Vietnamese market, we see that many systems of small and medium enterprises use old Linux distributions or manually install Web Servers and do not have a mechanism to automatically update patches periodically. These systems will be the most vulnerable targets when automated vulnerability scanning tools integrate HTTP/2 Bomb exploit code.
Another notable point is the role of AI. OpenAI Codex's automatic discovery of vulnerabilities by combining two independent techniques shows that large language models (LLMs) have moved beyond their role as conventional coding aids. They have begun to be able to analyze complex business flow logic to automatically generate exploit chains. This poses a big challenge for defense teams when the attacker's speed of finding vulnerabilities is accelerated many times thanks to AI.
Recommended action
Instantaneous (0-24 hours)
NGINX: Update to version 1.29.8 or later. If you cannot update, configure HTTP/2 to turn off by removing the http2 keyword in the listen configuration or setting http2 off;.
Apache httpd: Update module mod_http2 to version v2.0.41+. If updating is not possible, remove the HTTP/2 configuration by setting: Protocols http/1.1
Envoy: Immediately apply the patch in versions 1.35.11, 1.36.7, 1.37.3, 1.38.1.
Microsoft IIS: Install the June 2026 Patch Tuesday (CVE-2026-49160) on the affected Windows Server operating system.
Short term (1-7 days)
Configure worker process memory limits at the operating system level using cgroups (for Linux) or ulimit -v. Ensure that when a process consumes more than its RAM limit, the operating system automatically releases that process via OOM-killer and restarts a new process instead of dragging the entire system into a suspended state.
Configure front-end WAF/Reverse Proxy devices to apply a policy that strictly limits the maximum number of headers per request (including discrete cookie parts).
Long term
Build a process to automatically update operating system patches and edge server software at least monthly.
Set up a system to monitor resource performance (RAM, CPU, Swap) and automatically warn when these indicators exceed safe thresholds in a short time to activate the incident response process early.
Reference
New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare
New 'HTTP/2 Bomb' DoS attack crashes web servers in under a minute
Codex Discovered a Hidden HTTP/2 Bomb - Calif
publications/MADBugs/http2-bomb at main · califio/publications
