HTTP/2 denial of service NGINX web security vulnerability

The HTTP/2 'Bomb' Flaw Hitting NGINX, Apache and Friends — And What To Actually Do About It

3 June 2026

A newly discovered vulnerability in the HTTP/2 protocol, dubbed the "HTTP/2 Bomb," allows attackers to launch remote Denial-of-Service (DoS) attacks against widely used web servers and services, including NGINX, Apache, IIS, Envoy, and Cloudflare. The attack exploits weaknesses in how HTTP/2 handles certain requests, overwhelming servers with minimal effort from the attacker. Organizations are advised to take proactive steps to secure their systems against such vulnerabilities, particularly as AI is increasingly being used to discover and exploit security flaws.

A newly disclosed vulnerability in the HTTP/2 protocol is causing headaches across a surprisingly wide slice of the web stack. NGINX, Apache, IIS, Envoy, and Cloudflare are all affected. The attack class, being called an HTTP/2 continuation flood or 'bomb', lets a remote attacker trigger a denial-of-service condition without needing authentication or a particularly exotic setup. Just a malformed stream of CONTINUATION frames and your server starts having a very bad day.

What makes this one sting is the breadth. These aren't obscure edge-case servers. NGINX alone powers a substantial chunk of the public internet. When a protocol-level flaw cuts across this many implementations simultaneously, patching becomes a coordination exercise rather than a straightforward fix.

AI tools are increasingly being credited with finding this class of vulnerability before attackers do, which is genuinely useful. Automated analysis can churn through protocol implementations at a scale and speed that human researchers simply cannot match. Whether AI 'discovered' this particular flaw or merely assisted is beside the point. The finding is real and the exposure is significant.

So, what should you actually do?

First, patch. Check your vendor advisories now. Most of the affected projects have either issued fixes or are in the process of doing so. Running unpatched HTTP/2-capable infrastructure at this point is an unnecessary risk.

Second, consider whether you need HTTP/2 enabled everywhere. If you are running internal services that have no business supporting it, turning it off is a perfectly valid interim measure while you wait for patches to stabilise.

Third, review your rate limiting and connection handling configuration. Many of these protocol-level DoS attacks can be blunted by tightening limits on concurrent streams and header sizes. Not a fix, but a useful speed bump.

Fourth, monitor your traffic patterns. A sudden spike in connection overhead or CPU usage from your web tier without a corresponding rise in legitimate requests is worth investigating. HTTP/2 bomb attacks tend to be expensive server-side while appearing relatively quiet on the wire.

Fifth, if you are sitting behind a CDN or a DDoS mitigation provider, verify their mitigations are actually in place. 'Cloudflare is affected too' should give you pause if you were assuming your CDN was absorbing all your risk here.

The broader takeaway is that protocol-level vulnerabilities are not going away, and the attack surface keeps expanding as more of the stack adopts newer protocol versions under the assumption that someone else has already done the security review. Sometimes nobody has.