HTTP/2 Reset Stream Flooding

How HTTP/2 Reset Stream Flooding Works

HTTP/2 Reset Stream Flooding exploits a protocol feature that normally helps endpoints abandon work quickly. Instead of using it sparingly, an attacker opens many streams and repeatedly resets them, turning a control signal into a volume attack that forces the server, proxy or load balancer to track churn, tear down state and spend CPU on avoidable protocol handling.

The abuse is effective because HTTP/2 is designed for multiplexing and efficient stream management. When that machinery is stressed at scale, the bottleneck is often not bandwidth but per-connection and per-stream processing, especially in front-end gateways that terminate TLS and mediate traffic for many downstream services.

Why It Can Consume So Much Work

A reset does not just “cancel” a request in a cheap way. The receiver still has to parse frames, maintain stream state, update flow-control bookkeeping and decide what to do with the underlying connection. With enough concurrent activity, that overhead can become disproportionate to the attacker’s cost, which is the core denial-of-service imbalance.

This pattern is particularly harmful when intermediaries share the burden. A load balancer or application gateway may absorb the flood before the origin ever sees it, but the defender still loses capacity at the edge, which can starve legitimate users and amplify collateral strain across a fleet.

Where Exposure Usually Sits

Exposure is usually concentrated in internet-facing HTTP/2 endpoints, reverse proxies, API gateways and load balancers, especially where HTTP/2 is enabled broadly without protocol-specific limits. Services that depend on front-door mediation for routing, TLS termination or request fan-out are the most likely to feel the effect first.

For teams running gRPC or other HTTP/2-dependent stacks, the issue is often part of the transport layer rather than the application logic itself. That means the right place to look is not only the code path, but also the Load Balancer Security Guide, the gRPC Security Guide, and the HTTP/2, HTTP/3 and QUIC Security Guide for protocol limits and edge-hardening patterns.

Detection and Defences

Defence starts with recognising the pattern: unusually high rates of short-lived streams, repeated resets from the same client or subnet, and elevated edge CPU with comparatively low application throughput. Those signals often point to protocol abuse rather than ordinary traffic spikes.

Mitigations are usually protocol-aware and should be applied at the edge where possible. Common controls include stream and connection limits, reset-rate thresholds, sensible idle and request timeouts, degradation controls, and enough telemetry to distinguish normal client retries from abusive churn. The broader principle is to make expensive request handling fail cheaply.

Risk and Threat Considerations

Reset-stream floods matter because they can exhaust shared front-end resources even when the origin application is healthy. The result is degraded availability, uneven protection across services and a higher chance that a relatively small amount of attacker traffic causes visible disruption.

Failure mechanism: The attacker uses repeated stream creation and reset cycles to force disproportionate protocol-processing work, consuming CPU, connection slots and gateway capacity faster than defenders can clear it.

Impact: Legitimate traffic is delayed or dropped, edge components may become unstable, and load-balanced services can experience partial or complete availability loss before traditional application-layer alarms trigger.

Practitioner Guidance

Why practitioners should care: This attack is a transport-layer exhaustion problem, so application-only tuning is usually insufficient. Teams should validate how proxies, gateways and load balancers behave under reset-heavy traffic, not just whether the origin can survive ordinary HTTP load.

What to watch for: Alert on abnormal RST_STREAM volume, rapid stream churn, unexpected edge CPU saturation and sharp mismatches between accepted connections and useful request completion. Those signs often appear before user-facing outages become obvious.

Practitioner takeaway: Treat HTTP/2 limits as part of production resilience engineering, not as a niche protocol tweak, because edge-layer overload is where this attack class usually wins.

Related resources from NHI Mgmt Group

• HTTP/2
• Why does HTTP parameter pollution create risk for authentication and password reset flows?
• How should API teams respond when an HTTP/2 rapid reset vulnerability is disclosed in their gateway stack?
• Why does the HTTP/2 rapid reset pattern create denial of service risk for servers?