💣 Understanding the HTTP/2 Bomb: How a Tiny Request Can Melt a Server

Turns out, that cleverness can backfire — badly.

A few months ago, security researchers dropped news about something called the HTTP/2 Bomb. No botnets. No massive bandwidth. Just one ordinary laptop, a tiny request, and suddenly — gigabytes of server RAM disappear. In seconds.

Let's unpack how that works. But first, some basics.

🧱 How normal HTTP works (no magic)

You open a website. Your browser sends something like:

GET /products HTTP/1.1
Host: example.com
User-Agent: Chrome
Cookie: session=abc123

GET /products HTTP/1.1
Host: example.com
User-Agent: Chrome
Cookie: session=abc123

Server reads it, sends back a response. Done.

But every request carries the same heavy headers: Host, User-Agent, Cookie, Accept-Language… over and over. Wastes bandwidth.

🔒 HTTPS just wraps it

HTTPS doesn't change HTTP's logic. It just adds TLS encryption.

• Without HTTPS: your password travels in plain text (like a postcard).
• With HTTPS: it's a sealed envelope. People see the envelope, not the letter inside.

So HTTPS is good, but it doesn't fix the "repeating headers" problem.

⚡ Why HTTP/2 was built

HTTP/1.1 was slow in some ways. So HTTP/2 brought three big ideas:

• Multiplexing (send multiple requests at once)
• Flow control (don't overwhelm the client)
• Header compression (called HPACK)

The goal: less bandwidth, faster sites, lower latency.

But the HTTP/2 Bomb attack abuses two of these: HPACK and flow control.

🗜️ HPACK — the compression trick that becomes a weapon

HPACK is like a small dictionary shared between client and server.

First request: Client sends Cookie: session=abc123. Both store it in a table.

Table entry #1 → Cookie: session=abc123

Second request: instead of sending the whole header again, client just says "#1". That's maybe one byte instead of 30.

Great for performance. But…

💀 How an attacker twists HPACK

Step one: attacker stores a single header entry:

#1 → Cookie: A

#1 → Cookie: A

Step two: send thousands of references to that entry.

#1
#1
#1
#1
…

#1
#1
#1
#1
…

The attacker sends maybe 1 KB of data. But the server? It expands every reference, often creating internal structures per occurrence.

Result:

1 KB in → 100 MB, 500 MB, even 1 GB+ of memory allocated on the server.

That's called resource amplification.

🚰 The second knife: flow control

Normally the server processes a request, sends a response, and frees memory.

HTTP/2 has flow control — the client can say: "I'm ready to receive X bytes".

The attacker says: "I can receive 0 bytes".

Now the server can't send the response. The response stays queued. The memory stays allocated. And the attacker sends a tiny keep‑alive packet every few seconds so the connection never times out.

Memory locked forever.

💥 Put them together

• Abuse HPACK → server allocates huge RAM.
• Abuse flow control → that RAM cannot be freed.

Now imagine thousands of such requests. RAM runs out. Workers get blocked. Server stops responding. Website goes down.

That's the HTTP/2 Bomb.

🍔 A stupidly simple analogy

Walk into a restaurant. Tell the kitchen: "Make 10,000 burgers." They start cooking. Then you say: "Don't serve any. Keep them on the counter."

The kitchen fills with burgers. No space for new customers. Restaurant dies.

• Restaurant = server
• Burgers = RAM
• You = attacker
• Counter = flow control queue

🧠 The real engineering lesson

A lot of backend systems assume: small request = small cost.

This bomb proves that's dangerously wrong.

Whenever you build an API, a proxy, a database, or anything that accepts remote input, ask yourself:

How much work (CPU, memory, disk, network) can one single tiny request trigger?

If the answer is "a huge amount" without limits — you have a vulnerability.

HPACK itself is fine. Flow control itself is fine. The problem is combining memory amplification with indefinite pinning.

🛡️ Final takeaway

The HTTP/2 Bomb isn't just a weird bug. It's a warning: Modern protocols optimize for speed, but they can be twisted into weapons.

Always design for the worst‑case per request, not the average case.

And if you ever hear someone say "it's just a small request"… show them this article. 💣

Liked this? Clap, share, or yell at a colleague who still thinks HTTP/1.1 is slow enough to ignore.