HTTP/2 Bomb: one byte on the wire, seventy in memory, repeated until the server gives

Two old flaws, assembled together

Neither of the two ideas making up this attack is new. The assembly is what makes it effective, and that is why it is worth looking at: it shows how a weakness that is tolerable on its own becomes a problem once combined with another tolerable one.

HTTP/2 compresses headers through a mechanism called HPACK. The idea is reasonable: many headers repeat identically across consecutive requests — User-Agent, cookies, Accept — and resending them in full every time is waste. So HPACK keeps a dynamic table: the first time, the header travels in full and gets stored; from then on the client sends just an index, a handful of bytes, and the server reconstructs the rest.

That is compression, and therefore also an asymmetry: what the client spends to send is not what the server spends to handle. It is precisely the structure of every compression bomb, from the ZIP bomb onwards.

The research behind CVE-2026-49975 exploits that asymmetry directly. An almost-empty header is inserted into the table once, then referenced thousands of times. Each reference costs the sender roughly one byte on the wire; it costs the receiver the internal bookkeeping needed to represent that entry — on the order of seventy bytes per reference, per the public description of the technique.

The ratio is what matters. An amplification factor of that size means any sender, on a home connection, can make a server allocate an amount of memory wildly out of proportion to what producing it cost.

1. 01
   Step 1

   an almost-empty header enters the HPACK dynamic table once
2. 02
   Step 2

   it is referenced thousands of times: ~1 byte on the wire, ~70 bytes allocated
3. 03
   Step 3

   flow control holds the connection open, so the memory is never released

The second piece is the slowloris part. HTTP/2 flow control lets a client regulate how much it is willing to receive: declare you want nothing, and the server sits there with a prepared response and a hanging connection. Applied here, it serves to stop the memory from being freed: the allocated structures are not torn down, because the exchange has not finished.

Compression bomb plus stall: occupancy climbs and never falls.

What the sources say, and with which numbers

For Apache HTTP Server the position is clear and verifiable: the defect sits in mod_http2, covers versions 2.4.17 through 2.4.67, and the fix is in 2.4.68.

The scores deserve a note, because the gap between them is not a mistake. CVSS v3.1 gives 7.5, the typical score for a network-reachable, unauthenticated denial of service: no confidentiality or integrity impact, high impact on availability alone. CVSS v4.0 gives 8.7, higher, because v4 weighs automatability and attack conditions differently. Neither is wrong: they measure slightly different things, and which number to use depends on the metric your organisation adopted.

On reach, public sources describe the attack as relevant to widespread HTTP/2 implementations — nginx, Apache HTTP Server, Microsoft IIS, Envoy and Cloudflare Pingora are all named — and estimates in the range of hundreds of thousands of sites potentially reachable in default configuration are circulating. This is where to stop: those estimates do not come from an official advisory and their methodology is not public. We report them as an order of magnitude indicated by the research, not as verified data.

On the product side, Broadcom published a note for VCF Operations and VCF Operations for Logs; 3CX and several perimeter-protection vendors announced mitigations. The usual signal that a defect touches a layer common to many different products.

What makes this CVE low-urgency and high-interest

It needs saying plainly, because it is what matters most for anyone deciding what to patch first: there is no reported in-the-wild exploitation. The vulnerability does not appear in the CISA KEV catalog, and public sources in June 2026 explicitly reported no observed attacks. If your priority is "what is coming at me today", this is not at the top of the list.

Which brings us to why it is worth discussing anyway.

It is a pure availability vulnerability. Nobody gets in, nobody reads anything, nobody leaves with data. It is the vector organisations systematically underweight in planning, because in internal language "security" tends to mean "not getting things stolen". Then the service goes down on a Monday morning and the conversation changes.

It is protocol debt, not a typo in a line of code. HPACK was born to save bandwidth in an era when bandwidth was the scarce resource. That trade — spend memory and CPU to save network — was accepted knowingly. It still makes sense; but the asymmetry it introduces is exploitable by construction, and every so often someone finds a way to measure it in full. This is not the first family of HTTP/2 denial-of-service flaws, and in all likelihood not the last.

The attacker's cost is close to zero. That is the property that makes flaws like this attractive even when the score is unimpressive: no infrastructure needed, no botnet, no privileged network position.

What to do

Update, where the vendor allows it. For Apache the path is 2.4.68. For other servers and for the appliances terminating TLS and HTTP/2 on your behalf — load balancers, CDNs, WAFs, reverse proxies — the information belongs in each vendor's own advisory, because the same identifier maps to different version numbers.

Map where HTTP/2 is actually terminated. This is the most useful operational step and the one most often missing. In many architectures the application server does not speak HTTP/2 to the world: a load balancer or a CDN sits in front. In that case the component to update is the one in front, and patching only the server behind it produces a false sense of work done.

Check your connection limits. Maximum concurrent streams, maximum permitted HPACK dynamic table size, timeouts on connections that make no progress. These knobs have existed in web servers forever and in production usually sit at their defaults. They do not fix the vulnerability, but they narrow what a single connection is allowed to ask for.

Know how you respond to a DoS. That is worth more than this specific patch, and it will still be worth it for the next one in this family. Who notices the service is down? How long does that take? Is there a way to put the service behind protection while you investigate, or is it trial and error? These are questions better answered beforehand.

The point

It steals nothing and it leaves nothing behind. It only takes the service away from everyone else, using a feature designed to be efficient.

Efficiency, when it is asymmetric, is always also a lever. The flaw is not in having chosen it: it is in having forgotten about it.