Most denial-of-service attacks require scale: botnets, amplification reflectors, significant bandwidth. HTTP/2 Bomb, the vulnerability disclosed on June 3, 2026, requires none of those things. A single attacker on a home internet connection can exhaust tens of gigabytes of server memory in under a minute - and bring down NGINX, Apache HTTP Server, Microsoft IIS, Envoy, or Cloudflare Pingora in the process.
The underlying CVE assigned to the Apache variant is CVE-2026-49975. The broader attack affects all five server platforms in their default configurations, and a public proof-of-concept was released the same day as disclosure. This is not a vulnerability you can treat as a future-maintenance item.
What is HTTP/2 Bomb, and why does it matter?
Before getting into the technical details, it helps to understand the impact in plain terms.
HTTP/2 is the version of the web's core communication protocol that most servers have been running for the past several years. It was designed to be faster and more efficient than its predecessor. And it largely is. But that efficiency comes from a set of features that, when deliberately misused, can be turned against the server.
A denial-of-service (DoS) attack is one that makes a service unavailable. Not by breaking in, but by overwhelming it until it stops responding. Ordinarily, doing this requires either a lot of bandwidth (flooding the network) or a botnet of thousands of infected machines working together. HTTP/2 Bomb bypasses both requirements.
The attack works because of two features in the HTTP/2 protocol that were each known to have abuse potential, but had never been combined in this particular way before:
Feature one: header compression. HTTP/2 uses a scheme called HPACK to compress the metadata (headers) that accompanies every web request. It works by letting a sender say "use that header we sent earlier" with just a single byte, rather than repeating the full header each time. The server then has to reconstruct the full header from its memory. One byte in, hundreds to thousands of bytes of work out — that's the amplification.
Feature two: flow control. HTTP/2 lets a client tell the server "don't send me anything yet" by advertising a zero-byte receive window. The server pauses, waiting for permission to send. It holds all the memory it has allocated for that request in place until the client gives the green light.
HTTP/2 Bomb chains these two features: send thousands of single-byte header references per request to force the server to allocate a large amount of memory, then hold the connection open indefinitely so that memory is never freed. Repeat across enough requests, and the server's memory fills up completely, at which point it stops responding to everyone.
The numbers are striking. In testing against default server configurations, a single client was able to exhaust 32 GB of server RAM in approximately 10 seconds against Envoy, 18 seconds against Apache HTTP Server, and 45 seconds against NGINX and Microsoft IIS. Against IIS, 64 GB was consumed in the same 45-second window.
This is an attack that requires no authentication, no special access, no botnet, and no exotic tooling. Anyone with a working internet connection and the public proof-of-concept code can run it.
How was it discovered?
The attack was discovered by researcher Quang Luong at offensive security firm Calif, with a notable twist: the initial discovery was made by OpenAI's Codex software agent, not by a human researcher manually reviewing protocol specifications. Luong was guiding Codex in examining HTTP/2 implementations when it identified the combination of known techniques that produced the attack.
The discovery is interesting for a reason beyond the vulnerability itself: it illustrates that the gap between a published security patch and a working exploit is now very short when capable AI tools are available. Calif noted that after they disclosed the NGINX and Apache fixes, which were committed publicly to open-source repositories, any competent AI model could read those code diffs and derive the attack against Microsoft IIS, Envoy, and Pingora. That is in fact how they confirmed the wider impact.
Responsible disclosure was made to NGINX in April 2026, and to Apache on May 27. Both responded quickly: NGINX shipped a fix the day after notification, and Apache's fix was committed the same day it was received. The CVE identifier CVE-2026-49975 was assigned to the Apache variant.
What is actually happening technically
There are two layers to how this exploit works, and understanding both is useful for making good remediation decisions.
The amplification
HTTP/2's header compression (HPACK) works with a shared memory table. A sender can register a header in that table once, and subsequently refer to it with a single-byte index. The receiver must allocate and store a full copy of that header every time it sees a reference.
The classic attack against this mechanism, known since 2016, was to stuff a large value into the table and reference it repeatedly. Servers responded by capping the total size of decoded headers.
HTTP/2 Bomb uses a different approach: the referenced header is nearly empty. The amplification doesn't come from the header's content at all; it comes from the internal bookkeeping the server allocates around each entry: memory structures, metadata, allocator overhead. Those per-entry costs are not covered by decoded-size limits, because there is almost nothing to decode. That is what allowed this variant to bypass the defences that servers put in place after 2016.
For Apache and Envoy, which cap header count rather than decoded size, there is an additional bypass. The HTTP/2 specification explicitly permits splitting a Cookie header into one field per cookie value. Neither server was counting those individual cookie fields against its header-count limit, and cookies provided a path to even higher amplification ratios: Apache rebuilds the full merged cookie string on every additional crumb, leaving older copies live in memory until the stream closes.
The measured amplification ratios per server are as follows:
| Server | Amplification ratio | Memory consumed in demo |
|---|---|---|
| Envoy 1.37.2 | ~5,700:1 | ~32 GB in ~10 seconds |
| Apache httpd 2.4.67 | ~4,000:1 | ~32 GB in ~18 seconds |
| nginx 1.29.7 | ~70:1 | ~32 GB in ~45 seconds |
| Microsoft IIS (Windows Server 2025) | ~68:1 | ~64 GB in ~45 seconds |
The hold
Amplification alone would be damaging but recoverable: once the request completes, the server would free the memory. The second component prevents that.
HTTP/2 flow control allows a client to set its receive window to zero, meaning the server cannot send any data until the client expands that window. The attack sends a zero-byte window at the start of each request, then trickles one-byte WINDOW_UPDATE frames just frequently enough to reset the server's send timeout. The request never completes, the server never frees the allocated memory, and the client holds the connection open for as long as it likes - at essentially no cost.
As the Calif researchers noted, a 70:1 amplifier would be harmless if the memory were freed when each request completed. It becomes an attack precisely because HTTP/2 allows the client to pin that memory indefinitely. The severity is a product of both components working together.
Why this is a specification problem, not just an implementation problem
One reason five independent server implementations all shipped the same vulnerability is that the root cause is in the protocol specification itself. RFC 7541, the HPACK specification, frames memory risk purely in terms of amplification ratio and treats a configuration setting for the header table size as the sufficient bound. It does not account for per-entry bookkeeping overhead, and it does not address what happens when an attacker uses flow control to prevent the memory from ever being freed. Five engineering teams read the same specification and drew the same conclusions, because the specification pointed them in the same direction.
Who is affected?
A Shodan analysis at the time of disclosure identified more than 880,000 public-facing websites running an affected server with HTTP/2 enabled. The affected server software in its default configuration includes:
- NGINX (all versions prior to 1.29.8 / stable branch patch pending)
- Apache HTTP Server (all versions with mod_http2 prior to v2.0.41)
- Microsoft IIS (no patch available as of disclosure; Windows Server 2025 confirmed affected)
- Envoy (no patch available at disclosure; Envoy has since released patches that appear to address the attack)
- Cloudflare Pingora (Cloudflare states existing DDoS mitigations automatically detect and protect against this attack)
Many of those 880,000 exposed servers sit behind content delivery networks (CDNs) or reverse proxies, which provide meaningful indirect protection. However, any CDN or reverse proxy that is itself running affected software is directly vulnerable; and Pingora, Cloudflare's own proxy engine, was confirmed to be in scope.
The risk is highest for organisations running NGINX or Apache as a directly internet-exposed origin, API gateway, or load balancer without a protective CDN or proxy in front. Organisations running Envoy as their service mesh edge or API gateway face the highest amplification ratio of any affected product.
Active exploitation status
No evidence of active in-the-wild exploitation was reported at the time of disclosure. However, the public release of working proof-of-concept scripts on June 3 significantly lowers the bar for any attacker who wants to weaponise this. The PoC requires no compilation, no special credentials, and no prior access; it is a script that any operator can run against any reachable server.
The Calif researchers explicitly noted that the commit-to-exploit path for the additional affected platforms (IIS, Envoy, Pingora) was derived directly by an AI model reading the public NGINX and Apache fix commits. That path is available to anyone. The window for unhurried response is narrow.
What should you do?
1. Determine which affected servers you are running
Identify every internet-facing service running NGINX, Apache HTTP Server, Microsoft IIS, Envoy, or Cloudflare Pingora with HTTP/2 enabled. This includes origin servers, internal API gateways, service mesh proxies, and Kubernetes ingress controllers. If HTTP/2 is enabled in the default configuration and you have not explicitly overridden it, assume it is on.
2. Patch where patches are available
NGINX: Upgrade to version 1.29.8 or later. This release introduced a max_headers directive with a default ceiling of 1,000 headers per request, which closes the attack path.
# After upgrading, verify the running version:
nginx -v
# The max_headers directive is active by default in 1.29.8+.
# If you wish to set it explicitly in your configuration:
http2_max_header_size 1000;
Update commands by distribution:
# Ubuntu / Debian
sudo apt-get update && sudo apt-get install nginx
# RHEL / Rocky / AlmaLinux / Amazon Linux
sudo dnf update nginx
# SUSE / openSUSE
sudo zypper update nginx
# Arch Linux
sudo pacman -Syu nginx
Apache HTTP Server: Apply mod_http2 v2.0.41 from the standalone mod_http2 releases. This fix causes Cookie header crumbs to count against the LimitRequestFields limit, which blocks the cookie-bypass amplification path. This fix is available from the standalone releases and in the Apache trunk; it is not yet in a versioned 2.4.x release at time of writing, so consult Apache's security advisories for the current status.
After updating mod_http2, restart Apache and verify:
apachectl -M | grep http2
apachectl configtest && sudo systemctl reload apache2
Envoy: Envoy released patches on June 3, the same day as disclosure. Update to the patched release and consult Envoy's security advisory for version-specific guidance.
Microsoft IIS: No patch is available at time of writing. See the interim mitigation below.
Cloudflare Pingora: No action required for Cloudflare-managed infrastructure. Cloudflare has confirmed that existing DDoS mitigation architecture automatically detects and blocks this attack.
3. If you cannot patch immediately: disable HTTP/2
For any affected server where patching is not immediately possible, disabling HTTP/2 eliminates the attack surface entirely. This will degrade performance for HTTP/2-capable clients but keeps the service operational and removes the vulnerability.
NGINX:
# In your server block or http block:
http2 off;
Apache HTTP Server:
# In httpd.conf or virtual host configuration:
Protocols http/1.1
After making configuration changes, test and reload:
# Apache
apachectl configtest && sudo systemctl reload apache2
# NGINX
nginx -t && sudo systemctl reload nginx
Microsoft IIS: Disable HTTP/2 via the registry key or IIS configuration. Consult Microsoft's documentation for your specific Windows Server version. As an interim measure, placing a reverse proxy or WAF in front that terminates HTTP/2 and forwards only HTTP/1.1 to the IIS origin eliminates the exposure while retaining HTTP/2 for clients at the edge.
4. Apply resource limits as a defence-in-depth measure
For deployments that cannot immediately patch or disable HTTP/2, enforcing per-worker memory limits provides a meaningful backstop. An out-of-memory worker that is killed and respawns is a far better failure mode than a machine pushed into swap, where every other workload on the host degrades.
# Example: enforce a 2 GB memory limit on the NGINX worker process group
# using cgroups (systemd slice configuration)
# Consult your distribution's documentation for cgroup v2 syntax
# Or enforce via ulimit in the service unit:
# LimitAS=2G in the [Service] section of nginx.service
Container-based deployments should enforce memory limits at the container level to achieve the same protection.
5. Verify WAF and CDN coverage
If your origin servers sit behind a WAF or CDN, verify that the CDN itself is not running a vulnerable version of an affected server (particularly relevant for Cloudflare Pingora, where Cloudflare has confirmed protections are in place, and for any self-hosted CDN or proxy running NGINX or Envoy). For WAF configurations, adding a hard per-request HTTP header count limit, if your WAF supports it, is a useful mitigation in both the short and long term.
Detection
HTTP/2 Bomb produces server-side memory pressure and, at extremes, process crashes or OOM kills. These are observable through standard monitoring:
Memory utilisation: An anomalous spike in RSS memory for your web server process, particularly one that grows linearly without corresponding request volume, is a strong indicator of this attack in progress.
HTTP/2 connection anomalies in access logs: Look for connections that open and persist for unusually long durations without completing. In NGINX, connection-level metrics can be exposed via the ngx_http_stub_status_module. In Apache, mod_status exposes active worker states.
OOM killer activity (Linux):
# Check for OOM kills involving web server processes
journalctl -k | grep -i "oom\|out of memory" | grep -i "nginx\|apache\|httpd\|envoy"
dmesg | grep -i "oom\|killed process"
NGINX error logs:
grep "worker process" /var/log/nginx/error.log | grep -E 'exited|signal'
journalctl -u nginx --since "24 hours ago" | grep -i "started\|stopped\|failed"
Apache error logs:
grep -E 'AH02032|segfault|child.*exit' /var/log/apache2/error.log
Unlike some of the Linux kernel privilege escalation vulnerabilities covered in recent CrowdSOC posts, HTTP/2 Bomb does leave observable traces. The memory pressure is real, measurable, and detectable with standard infrastructure monitoring. Teams with memory utilisation alerting already in place should ensure their thresholds are tight enough to fire on a sudden spike before the server becomes fully unresponsive.
A note on the broader picture
HTTP/2 Bomb arrives during a period of unusually dense critical vulnerability disclosures. Our recent coverage of NGINX Rift, Apache Double-Free, and the Linux kernel privilege escalation series (Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, and ssh-keysign-pwn) has made May and early June 2026 an exceptional period for infrastructure security teams.
HTTP/2 Bomb is qualitatively different from most of the above. It is not a memory corruption flaw introduced by a coding mistake. It is an attack that arises from the interaction of two protocol features that are both working as specified, just not in a combination the specification authors considered. The fact that five independent, well-resourced engineering teams all produced the same vulnerable implementation is a consequence of the specification pointing them all in the same direction.
The discovery method is also worth flagging. This was not found by a human reading through RFCs with fresh eyes. It was found by an AI agent running on guidance from a researcher, and the same AI capability that discovered it was then used to derive exploits for additional platforms from public code commits. The time between fix being committed and exploit being available for other platforms is now measured in minutes, not weeks. That changes the calculus for how quickly patches need to be applied once a public fix exists for a related platform.
Summary
| CVE | CVE-2026-49975 (Apache variant; other platforms tracked separately) |
| Nickname | HTTP/2 Bomb |
| Type | Remote Denial of Service |
| Discovered by | Quang Luong / Calif (via OpenAI Codex), with Jun Rong and Duc Phan |
| Disclosed | June 3, 2026 |
| Affected | NGINX (< 1.29.8), Apache HTTP Server (mod_http2 < 2.0.41), Microsoft IIS, Envoy, Cloudflare Pingora |
| Not affected | Cloudflare-managed infrastructure (existing DDoS mitigations cover this); servers with HTTP/2 disabled or behind HTTP/1.1-only proxies |
| Attack vector | Remote, unauthenticated; single client on standard home internet connection sufficient |
| Immediate impact | Server memory exhaustion leading to unavailability (DoS); no RCE path |
| Public PoC? | Yes — published June 3, 2026 |
| Active exploitation? | None confirmed at time of writing |
| Immediate mitigation | Disable HTTP/2 (http2 off; / Protocols http/1.1) |
| Full fix (NGINX) | Upgrade to 1.29.8+ |
| Full fix (Apache) | Apply mod_http2 v2.0.41 |
| Full fix (Envoy) | Apply released patches per GHSA-22m2-hvr2-xqc8 |
| Full fix (IIS) | No patch available; disable HTTP/2 or front with HTTP/1.1 proxy |
| Estimated exposed surface | 880,000+ public-facing servers (Shodan, June 2026) |
HTTP/2 is not an obscure protocol feature — it is enabled by default on every major web server and carries a large fraction of the internet's traffic. A no-authentication, single-connection DoS with a public exploit targeting that surface is a patch-now situation, not a scheduled-maintenance item.
If you need help auditing your exposed HTTP/2 surface, verifying patch status across your fleet, or configuring per-worker memory limits as a defence-in-depth measure while patches are staged, get in touch. The combination of a low attack bar, wide affected surface, and public exploit code makes this one of the more operationally urgent disclosures of the year.