HTTP/2 Memory Exhaustion

How HTTP/2 Memory Exhaustion Works

HTTP/2 memory exhaustion is a denial-of-service pattern where a client can make an endpoint allocate far more memory than the request itself appears to justify. The imbalance matters because HTTP/2 is designed to carry many streams efficiently, so resource accounting failures can become severe very quickly.

The core issue is not simply that traffic is “large,” but that small or crafted inputs can trigger expensive internal state, such as header decoding work, compression handling, buffering, or stream bookkeeping. When the implementation fails to cap decoded cost, the server may spend memory long before it has enough signal to reject the request.

Why HTTP/2 Makes This Dangerous

HTTP/2 introduces features that improve performance under normal load, but those same features can increase exposure when resource limits are weak. Multiplexed streams, compressed headers, and flow control all create more places where an implementation must track state, and each of those bookkeeping paths can be abused if limits are missing or misaligned.

This makes memory exhaustion especially dangerous in front-end services, reverse proxies, gateways, and any shared HTTP stack where one abusive client can influence process-wide memory pressure. Once memory pressure rises, the effect is rarely limited to a single request, it can degrade unrelated traffic, trigger crashes, or force restarts that amplify outage impact.

What To Check In Exposure And Architecture

To understand exposure, organisations should identify every service that terminates HTTP/2, not only the application itself. The relevant questions are whether the endpoint is internet-facing, whether it sits behind a shared proxy or load balancer, and whether several applications depend on the same implementation library or server process.

It also helps to review vendor advisories and release notes for the HTTP/2 stack in use, because the practical risk often depends on how that stack handles header limits, compression settings, stream concurrency, and buffering defaults. A configuration that is safe in one deployment can still be exposed in another if the deployment allows large decoded state relative to input size.

Defensive Controls And Recovery Patterns

Mitigation usually starts with constraining resource growth before the server commits memory for decoded or queued work. That means enforcing tight bounds on header size, stream count, concurrent requests, and any buffering or compression-related expansion path, then validating those bounds under adversarial traffic rather than only normal load.

Where patching is delayed, compensating controls should reduce blast radius, for example by placing the service behind rate limits, isolating vulnerable listeners, reducing exposed attack surface, or temporarily preferring a safer protocol path where feasible. Because this is a denial-of-service condition, recovery planning should also assume restart, failover, and traffic shedding may be needed if exhaustion is already underway.

Detection And Post-Incident Review

Detection is strongest when memory growth is correlated with unusually small request volumes, repeated malformed or high-cost HTTP/2 patterns, or spikes in header-processing work. Operators should watch for process instability, excessive garbage collection or allocator pressure, and service saturation that is not explained by ordinary throughput.

After patching or reconfiguration, review whether the endpoint was only degraded or fully compromised through availability loss. In most cases the primary issue is service disruption rather than data theft, but post-incident review should still confirm whether logs, telemetry, or fallback paths show repeated attempts that would justify ongoing filtering or stricter protocol limits.

Risk and Threat Considerations

HTTP/2 memory exhaustion is dangerous because the attacker does not need to send a large payload to create disproportionate resource consumption. Small requests can still force expensive internal work, which makes the attack cheap to launch and potentially effective against shared infrastructure or high-value front doors.

Failure mechanism: The implementation accepts or expands request state faster than it enforces memory or decoding limits, so an attacker can drive allocator pressure through compression, header parsing, or stream bookkeeping.

Impact: The endpoint may become slow, refuse new connections, crash, or trigger cascading availability issues across services that share the same process, host, or front-end tier.

Practitioner Guidance

What to watch for: Treat any HTTP/2 deployment with custom proxying, aggressive compression handling, or shared listener infrastructure as a candidate for stress testing under adversarial conditions. The key judgment is whether decoded cost is bounded independently of request size and whether that bound still holds under concurrency.

Governance implication: Ownership should sit with the team that controls the HTTP/2 terminator, not only the application team, because the failure mode often lives in the transport layer or gateway configuration. Review and test those limits as part of release and change management, especially when libraries or defaults change.

Related resources from NHI Mgmt Group

• How should security teams reduce exposure to HTTP/2 memory exhaustion attacks on public web servers?
• What breaks when a worker-process memory corruption issue is exposed through crafted HTTP requests?
• What breaks when HTTP/2 stream cleanup is vulnerable to double-free memory corruption?
• Why does HTTP/2 increase the risk of memory-safety flaws in web servers?