The HTTP/2 Bomb (CVE-2026-49975): What Self-Hosters Need to Know

A single laptop can now exhaust a server's RAM in seconds

On June 2–3, 2026, security researchers disclosed CVE-2026-49975, nicknamed the “HTTP/2 Bomb.” It is a remote denial-of-service attack that can drive a vulnerable server to consume tens of gigabytes of memory in seconds — one demonstration exhausted roughly 32 GB of RAM in about 10 seconds against an Envoy proxy — using nothing more than a single residential internet connection. No botnet, no huge bandwidth, just one machine.

What makes this one notable: it affects nearly every major web server and proxy that speaks HTTP/2 — nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora — and at disclosure, scans found well over 800,000 public-facing servers exposed. It was also one of the first widely-publicized serious vulnerabilities surfaced with the help of an AI agent.

If you self-host, here is what the HTTP/2 Bomb actually is, why so many servers are exposed, and why a self-hosted iNetPanel box is structurally insulated from it — partly on purpose, and partly by a lucky accident of timing.

How the HTTP/2 Bomb works

HTTP/2 was designed to be efficient. The Bomb turns two of its efficiency features against the server:

• HPACK header compression. HTTP/2 lets a client send a header once, then refer back to it with a tiny index number instead of re-sending the whole string. That is great for performance — but it means a handful of bytes on the wire can expand into a large header that the server has to rebuild in memory. The Bomb sends thousands of single-byte references back to a crafted table entry, forcing the server to reconstruct large headers over and over.
• Slowloris-style connection holding and flow-control abuse. While that memory piles up, the attack keeps the connections open and the streams alive long enough that the server never gets a chance to free anything. The allocations stack up faster than they drain.

The result is a brutal amplification ratio — the gap between how little the attacker sends and how much the server is forced to allocate. Researchers measured roughly 5,700:1 on Envoy (hence ~32 GB in ~10 seconds), about 4,000:1 on Apache httpd, and about 70:1 on nginx. Even the “low” nginx figure means a trickle of attacker traffic translates into a flood of server memory pressure. Once RAM is exhausted, the kernel's OOM killer starts terminating processes and the site goes down.

Why so many servers are exposed

HTTP/2 is everywhere — it is the default for most modern sites because it genuinely makes pages load faster. That ubiquity is exactly the problem: any server terminating HTTP/2 directly from the public internet is a candidate. The maintainers have shipped fixes:

• nginx 1.29.8 introduces a new max_headers directive to cap the damage.
• Apache fixed it in mod_http2 2.0.41, ensuring fragmented header pieces count toward request field limits.

But patches only help the servers that actually get patched — and a self-hosted box that nobody updates for six months is precisely the kind of machine that stays vulnerable long after the headlines fade.

Why a self-hosted iNetPanel server is insulated

Here is the honest version of the story, because it matters: iNetPanel did not pin HTTP/1.1 as a rapid response to the Bomb. In v1.24.3 (released June 6, 2026, days after the disclosure) we pinned the Cloudflare→Apache origin connection to HTTP/1.1 to fix a completely different problem — cross-vhost content contamination, where HTTP/2 connection coalescing could occasionally serve one domain's content (say, its sitemap.xml) under another domain on the same server. The timing with the Bomb disclosure was a coincidence.

But that one change, combined with how iNetPanel is architected, means the Bomb has nowhere to land. There are three layers:

1. The origin isn't reachable from the public internet at all

Every iNetPanel site is served through a Cloudflare Zero Trust Tunnel with no open inbound ports. Your Apache origin does not listen on a public IP. An attacker cannot open a raw HTTP/2 connection to it and start sending Bomb frames, because there is no public socket to connect to in the first place. This is the same property that lets iNetPanel host from behind home CGNAT — and it happens to be a fantastic DoS posture.

2. The origin no longer speaks HTTP/2

As of v1.24.3, the Cloudflare→origin hop is pinned to HTTP/1.1 (via a managed Protocols http/1.1 directive, applied idempotently on update with a config test and automatic revert on failure). The HTTP/2 Bomb is, by definition, an HTTP/2 attack. An origin that doesn't negotiate HTTP/2 cannot be hit by it — patched mod_http2 or not. The vulnerable code path simply isn't in play.

3. Edge HTTP/2 termination is Cloudflare's job

Your visitors still get modern HTTP/2 and HTTP/3 — from Cloudflare's edge, which terminates it and re-speaks HTTP/1.1 back to your origin. Keeping the edge patched against attacks like this is Cloudflare's responsibility and operates at their scale, not yours. You get the performance of HTTP/2 for real users without owning the attack surface.

Stack those together and you get textbook defense in depth: even if your Apache happened to be running an unpatched mod_http2, the Bomb can't reach it directly (no open ports), can't ride the origin hop (HTTP/1.1 only), and would have to get past Cloudflare's edge to even try.

What every self-hoster should do right now

Whether or not you run iNetPanel, the HTTP/2 Bomb is a good prompt to check your exposure:

• Patch your web server. If you run Apache or nginx with HTTP/2 facing the internet directly, update to Apache mod_http2 2.0.41 / nginx 1.29.8 or later. On Debian 12, apt update && apt upgrade once the fix lands in your repo, and restart the service.
• Ask whether your origin needs HTTP/2 at all. If something else (a CDN, a reverse proxy, a tunnel) already terminates HTTP/2 for your visitors, your backend can safely speak HTTP/1.1 and shed this entire class of attack. That is exactly the posture iNetPanel now ships by default.
• Reduce your attack surface. The single most effective mitigation against remote DoS is to not expose the origin directly. A tunnel with no open ports means an attacker can't even begin. Our home server guide walks through setting this up.
• Keep your panel and OS updated. iNetPanel applies origin hardening automatically on update; the value of that only lands if you actually take the updates.

The bigger lesson for self-hosting

The HTTP/2 Bomb is a reminder that the riskiest thing a small server can do is expose powerful, complex protocol machinery straight to the open internet. The features that make HTTP/2 fast — header compression, multiplexing, flow control — are the same features that, weaponized, can melt a box from a single laptop.

The self-hosting answer isn't to give up on modern protocols; it's to put the complex, internet-facing parts where they belong (a hardened edge) and keep your own origin small, private, and boring. iNetPanel was built around that principle from day one: no open ports, everything through the tunnel, the origin doing the minimum. CVE-2026-49975 is just the latest example of why that architecture quietly pays off.

Want the no-open-ports setup for yourself? Install iNetPanel free in one command, or read the complete home-server guide to understand how the tunnel architecture works. You can also browse the documentation or learn more about the project.

This article is informational. CVE-2026-49975 details reflect public disclosures as of June 2026; always consult your web server and CDN vendors' advisories for the authoritative, current guidance and patch versions.