What Calif found goes the other direction entirely. The headers in this attack are nearly empty. There’s almost nothing to decode. The amplification doesn’t come from decoded content — it comes from the per-entry bookkeeping the server allocates around each header entry. One byte on the wire becomes one full header allocation in server memory, repeated thousands of times per request. The decoded-size limit never fires because it’s looking for something that isn’t there.

Then comes the hold. HTTP/2’s flow control mechanism lets clients set a zero-byte receive window, telling the server they’re not ready to receive data. The connection stays open. Every byte the server allocated for those header entries stays pinned in memory. The server can’t free any of it. The client pays nothing essentially to maintain this state. The server pays in RAM, continuously, for as long as the connection persists.

The Numbers Require Serious Attention

Security research is genuinely full of vulnerabilities that are technically real and practically marginal — attack conditions so constrained that exploitation at a meaningful scale would require resources most threat actors don’t have access to. This isn’t one of those.

A single client on a 100Mbps home broadband connection can render a vulnerable server inaccessible within seconds. Against Apache HTTPD and Envoy specifically, one machine consuming 32GB of server memory in approximately 20 seconds is what testing demonstrated. Not a theoretical maximum. Not an optimized lab environment. Demonstrated.

The attack requires no authentication. No knowledge of application architecture. No credentials. No prior access of any kind. Just HTTP/2, which the server is almost certainly running in default configuration, and the two techniques described above. The combination is stable, repeatable, and — for three of the five affected implementations — currently without a patch.

That last point matters considerably. NGINX and Apache HTTPD have fixes available. NGINX 1.29.8 introduces a max_headers directive that defaults to 1000, closing the per-entry allocation amplification path. Apache HTTPD’s fix landed in mod_http2 version 2.0.41. Both vendors have also published fallback guidance — disable HTTP/2 entirely if immediate patching isn’t operationally feasible, accepting the performance trade-off that decision involves.

Microsoft IIS, Envoy, and Cloudflare Pingora have no patch available as of this writing. Organizations running those implementations are currently choosing between waiting with full exposure or disabling HTTP/2 and absorbing the operational consequences.

What Envoy Exposure Actually Means at Enterprise Scale

Most vulnerability coverage treats this as a web server problem. For a large segment of enterprise infrastructure, it’s considerably more than that, and the Envoy exposure is where the blast radius becomes genuinely alarming.

Envoy isn’t just a web server. It’s the data plane for service mesh architectures — the proxy layer that sits between every service-to-service communication in Kubernetes environments running Istio and comparable frameworks. When Envoy is the component being exhausted, the conversation isn’t about a single public-facing endpoint going offline. It’s about the communication fabric of an entire application platform becoming unavailable.

In a Kubernetes cluster where every microservice-to-microservice call travels through an Envoy sidecar proxy, a successful HTTP/2 Bomb attack against the data plane takes down inter-service communication across the entire cluster. The blast radius scales with the size and complexity of the deployment. For organizations running distributed application architectures on service mesh infrastructure, this vulnerability deserves treatment as a platform availability risk, not a web server patch.

The internal network attack surface matters here, too. HTTP/2 is used for east-west service communication inside clusters, not only for external-facing traffic. Threat actors who have established any internal network access — through a compromised container, a lateral movement foothold, or a supply chain intrusion — can target Envoy from inside the cluster perimeter using the same technique. Network perimeter controls that might block an externally sourced attack do not protect against that scenario.

The Protocol Architecture Missed Something Fundamental

Calif’s analysis includes an observation that deserves considerably more attention than it’s received in mainstream coverage. The HTTP/2 specification frames memory risk almost entirely as an amplification ratio problem. That framing, it turns out, is only half the equation.

A 70:1 amplification ratio is harmless if the server frees the allocated memory when the request completes. HTTP/2 Bomb works because the protocol gives clients a legitimate mechanism — flow control — to prevent that memory from ever being freed. The ratio is irrelevant when the hold is indefinite. The specification’s authors were solving for a different problem and left this particular combination unaddressed.

This isn’t hindsight criticism of the HTTP/2 design team. It’s a structural observation about what happens when two separately reasonable protocol features interact in ways that create resource exhaustion conditions neither feature was designed to produce. Server implementations patched against known ratio-based attacks remained exposed because the resource pinning pathway wasn’t part of the threat model they were defending against.

Enterprise architecture teams actively evaluating HTTP/3 adoption should be sitting with this observation for a moment. The assumptions embedded in HTTP/2’s memory management model didn’t survive contact with adversarial research. Before those assumptions migrate into next-generation protocol deployments, the question of whether HTTP/3’s resource management model has the same structural blind spots is worth asking explicitly — while there’s still time to influence implementation decisions.

Operational Response for Teams Unable to Take a Clean Patch Path

For NGINX and Apache HTTPD, the way ahead is well-known and urgent. Apply patches immediately and ensure validation coverage across all instances, from containers to CI/CD pipeline infrastructures to dev environments, where server version control is typically not as rigorously managed as in production.

With respect to IIS, Envoy, and Cloudflare Pingora, where no patches are yet available, the decisions will be tougher. First, consider whether HTTP/2 can be disabled in a way that will not disrupt applications or cause unacceptably increased latency regressions. For those instances where HTTP/2 cannot be disabled, consider aggressively rate-limiting connections and placing strict connection limits per client, making it more expensive for attackers to maintain their attacks on vulnerable systems. Meanwhile, WAF signatures for anomalous HTTP/2 traffic (particularly long-running sessions with zero-byte flow control windows) will be partially helpful.

Organizations that are protected by Cloudflare, Fastly, or Akamai on the edge have the option of being somewhat safe from external attacks – but not east-west attacks using HTTP/2. This type of traffic does not travel through CDN edge infrastructure. In other words, until Envoy fixes its problem, you will remain vulnerable.

When it comes to inventory, this problem is universal. HTTP/2 is so ubiquitous that complete visibility of the services using HTTP/2 – internal APIs, load balancers, development environment, containers, etc. – can be rare compared to what security professionals expect. The first step to take in identifying your potential exposures is an inventory scan, and you should do that before anyone else takes advantage of it.

Another Important Thing About The AI Discovery Footnote

This vulnerability was discovered by Codex using techniques already known in the world, but chained together in a manner that was not known or documented by any human researchers. This is an important datapoint, as AI-based discovery of new vulnerabilities proves that such technology is no longer just a theoretical aid to the security research community but can actually produce actionable information about vulnerabilities in current production infrastructure.

The unpleasant part here is that any bad actor also has access to the technology for discovering vulnerabilities by chaining known attacks together using machine learning algorithms. Thus, AI-assisted vulnerability finding could result in a much faster timeline between discovering and exploiting the vulnerability compared to classical methods.

Patching HTTP/2 Bomb should be as urgent as its technical severity suggests.

Research and Intelligence Sources: calif.io

To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com