HTTP/2 Denial-Of-Service is an attack that uses the HTTP/2 protocol to overwhelm a server or intermediary with excessive requests, streams, or frame activity. It exploits protocol features such as multiplexing and header compression to consume CPU, memory, or connection resources faster than normal limits can handle.
How HTTP/2 denial of service works
HTTP/2 denial of service takes advantage of protocol behaviors that are efficient for normal traffic but expensive under abuse. The attacker does not need to saturate bandwidth; it is enough to force the server, reverse proxy, or load balancer to spend disproportionate CPU, memory, or connection state on managing streams, frames, and header processing.
This is why HTTP/2 attacks often look different from classic volumetric floods. The bottleneck is frequently application or intermediary capacity, not raw network throughput, and the service can fail even when traffic volumes appear modest. That distinction matters because the visible symptom is service slowdown or reset behaviour, while the actual exhaustion is internal resource pressure.
Why HTTP/2 features can be abused
HTTP/2 introduces multiplexing, stream prioritisation, binary framing, and header compression to improve performance. Those same features create opportunities for abuse when an attacker sends carefully crafted request patterns that multiply server work, increase parser overhead, or hold resources open longer than intended.
In practice, the danger is not the protocol itself but the mismatch between protocol flexibility and defensive limits. If intermediaries and origin servers do not enforce sane bounds on concurrent streams, frame rates, header processing, or request lifetimes, the attacker can create exhaustion with relatively small inputs.
For a broader view of the attack class and mitigation patterns, the Denial of Service at Application Layer Guide covers the resource exhaustion patterns that HTTP/2 attacks exploit, while the DDoS Protection Guide shows how rate limiting, scrubbing, and response runbooks fit into a broader defence strategy.
How organisations assess exposure
Exposure starts with inventory. Teams need to know which internet-facing services, CDNs, reverse proxies, ingress controllers, and application stacks actually speak HTTP/2, because the vulnerable path is often in the intermediary as much as in the origin service.
From there, review vendor advisories, patch notes, and hardening guidance for the specific server or proxy in use. HTTP/2 exhaustion issues can surface in multiple layers, so a service may be exposed even if the application code itself is unchanged. External testing should focus on the live edge path, not only on internal lab traffic.
Candidate resources such as the DDoS Response Playbook are useful because exposure assessment should be tied to escalation ownership, provider contacts, and the limits that operations teams can actually change during an incident.
Detection, remediation, and recovery
Detection should look for abnormal stream counts, repeated resets, header inflation, parser stalls, queue growth, and rising CPU or memory use on the edge tier. A service can be under attack even when packet volume is not exceptional, so observability at the connection and request layer is essential.
Remediation usually combines protocol-aware limits with compensating controls. Common measures include tighter bounds on concurrent streams, request and header size limits, shorter timeouts, connection throttling, and edge filtering or rate limiting where supported. If immediate patching or configuration change is not possible, teams often rely on upstream mitigation, temporary traffic shaping, or provider-assisted scrubbing.
After stabilisation, review whether the event caused partial availability loss, failed requests, or collateral stress on downstream services. In some environments, post-incident tuning is as important as the original fix because attackers often exploit whichever limit was left most permissive.
What to review after an HTTP/2 attack
Post-incident review should confirm whether the attack only caused disruption or whether it also exposed deeper control gaps. If the exhaustion reached application gateways, authentication tiers, or session infrastructure, the team should verify that no unrelated security telemetry was lost during the overload.
That review is also the time to check whether traffic was redistributed in ways that changed trust boundaries, such as failover to a less protected node or bypass of normal inspection. The practical lesson is that denial of service is not only an availability issue, it can also be a visibility and control issue if monitoring collapses before the attack does.
The most useful outcome is a clearer edge policy: what the service should tolerate, what it should reject, and which operational signals must trigger escalation before users notice impact.
Risk and Threat Considerations
HTTP/2 denial of service is especially dangerous when the protocol is terminated by shared infrastructure such as gateways, CDNs, or reverse proxies, because a single abusive client can consume disproportionate state across many downstream users. The attack may not require high traffic volume, only efficient abuse of multiplexing and frame handling.
Failure mechanism: The attacker drives expensive parsing, stream management, or header processing until CPU, memory, or connection slots are exhausted, causing degraded service or widespread resets.
Impact: The result can be partial or total outage, failed transactions, increased latency, and reduced defensive visibility while the overloaded tier is busy handling the attack.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | HTTP/2 DoS exposure depends on timely remediation of protocol and edge-component weaknesses. |
| Recommendation — Track and remediate HTTP/2-facing component weaknesses before they can be abused for service exhaustion. | ||
| NIST CSF 2.0 | PR.PS-05 — Backups of information are conducted, maintained, and tested | Availability attacks on HTTP/2 services justify resilient recovery and service-continuity planning. |
| Recommendation — Build recovery and continuity measures that preserve service availability during HTTP/2 exhaustion events. | ||
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | This control directly addresses resource-exhaustion attacks that overwhelm networked services. |
| SI-4 — System Monitoring | Detecting HTTP/2 abuse depends on monitoring abnormal protocol and resource-use patterns. | |
| Recommendation — Apply denial-of-service protections to limit abusive connection and request patterns at the edge. Monitor HTTP/2 traffic and resource telemetry for signs of stream, frame, or parser abuse. | ||
| OWASP ASVS | V13 — Configuration | HTTP/2 DoS mitigation relies on secure configuration of limits, timeouts, and request handling. |
| Recommendation — Configure protocol and gateway limits so abusive HTTP/2 traffic is rejected before it exhausts resources. | ||
Practitioner Guidance
What to watch for: Treat HTTP/2 as a configuration and capacity-management problem as much as a protocol feature. The most effective controls are the ones that make abusive concurrency, frame rate, and request lifetimes expensive for the attacker instead of the server.
Practitioner takeaway: Harden the edge first, then validate those limits under load testing that mimics protocol abuse rather than ordinary traffic.
Related resources from NHI Mgmt Group
- Why do HTTP/2-enabled reverse proxies increase denial-of-service risk in edge environments?
- Why does a malformed HTTP/2 header sequence create denial of service risk for servers?
- Why does the HTTP/2 rapid reset pattern create denial of service risk for servers?
- Why does an exposed Fluent Bit HTTP server increase the risk of denial of service, information disclosure, or remote code execution?