What attacks target HTTP/2?

HTTP/2 can be targeted by denial-of-service attacks that exploit stream, header, and connection handling, including rapid request flooding and malformed framing that consumes server resources. Defenders should watch for unusual concurrency, reset patterns, and header compression pressure, then apply protocol-aware limits, upstream protection, and current patches for the HTTP/2 stack in use.

How HTTP/2 Attacks Work in Practice

Most attacks against HTTP/2 do not depend on breaking encryption or bypassing authentication. They abuse how a server handles concurrency, framing, header compression, and stream lifecycle. That makes the most common outcome resource exhaustion, where the protocol stays technically valid but the server spends too much work managing malformed or excessive traffic. Defenders should think in terms of protocol behavior, not just request volume.

HTTP/2-specific abuse often uses many small requests, rapid stream creation, stream resets, oversized or repetitive headers, and malformed frame patterns to force disproportionate CPU, memory, or connection-state usage. A busy reverse proxy, load balancer, or application server can become unstable even when individual requests look harmless. The practical question is whether the stack enforces sane limits on streams, headers, and connection reuse under stress.

Attackers also benefit from the fact that HTTP/2 is usually deployed through shared infrastructure. A weakness in one layer, such as an upstream proxy, can amplify traffic before the application even sees it. For defenders, that means the relevant control point is often the edge, where protocol enforcement, normalization, and throttling can blunt abusive patterns before they cascade deeper into the stack.

Which HTTP/2 Behaviours Are Most Abused?

The most familiar attack pattern is denial of service through request floods, but HTTP/2 gives attackers several ways to make the flood more expensive. Rapid stream opening can pressure concurrency controls, while aggressive reset behavior can make servers waste effort creating and tearing down state. Header compression pressure can also become expensive when a server must repeatedly process large or adversarial header sets.

Malformed framing is another important class. Frames that violate expected sequencing, size, or state transitions can trigger error handling paths that are far more expensive than normal request processing. In well-implemented stacks, malformed traffic is rejected cheaply. In weaker implementations, the rejection path itself becomes the attack surface because the server spends cycles parsing, logging, buffering, or retrying instead of serving legitimate clients.

These issues are especially visible in shared environments that aggregate many applications behind one HTTP/2 terminator. A single noisy client can affect unrelated workloads if the control plane or proxy does not isolate per-tenant or per-origin limits well. For a broader view of web attack patterns that commonly include request manipulation and protocol abuse, see the Web Application Attacks Guide.

What Defenders Should Check and Tune First

Start by confirming whether the exposed component actually speaks HTTP/2 end to end, or whether it terminates HTTP/2 at a proxy and forwards to HTTP/1.1 internally. The control strategy depends on that boundary. If the edge terminates HTTP/2, the edge must enforce the limits. If the application stack handles HTTP/2 directly, the application server and its libraries need the same scrutiny.

Then validate the operational signals that reveal protocol abuse early: unusual concurrency, high rates of stream resets, bursts of short-lived connections, and spikes in header parsing cost. These are better indicators than raw request counts because HTTP/2 attacks often aim to make each request disproportionately expensive. Once those signals are visible, apply protocol-aware caps, sane connection reuse policies, and upstream protection that can absorb or rate-limit abusive flows before they reach the app tier.

Patching remains important because many HTTP/2 attacks depend on implementation details, not just the specification itself. If patching must wait, reduce exposure by tightening proxy limits, disabling unnecessary features in the HTTP/2 stack, and isolating sensitive services from public entry points where possible. CISA advisories are useful for tracking current exploit activity and response priorities, so defenders should correlate local findings with the latest guidance in the CISA cyber threat advisories.

Risk and Threat Considerations

HTTP/2 attack traffic is dangerous because it can look like normal protocol use while still exhausting shared resources. That creates a denial-of-service risk even when individual requests are authenticated, valid, or encrypted. In practice, the failure mode is often not one large spike but a sustained pattern that slowly degrades availability, increases latency, and destabilizes upstream infrastructure.

Failure mechanism: Attackers exploit expensive stream management, header handling, or frame parsing so the server spends more effort rejecting traffic than serving legitimate clients.

Impact: Availability loss can extend beyond one application to shared proxies, ingress controllers, and other services on the same edge path, especially where HTTP/2 traffic is concentrated.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-13 — Network Monitoring and Defense	HTTP/2 abuse is detected through anomalous concurrency and reset patterns.
Recommendation — Monitor edge traffic for protocol abuse patterns and alert on abnormal stream behavior.
NIST SP 800-53 Rev 5	SI-4 — System Monitoring	The answer centers on detecting malicious or abnormal HTTP/2 behavior at the edge.
Recommendation — Deploy monitoring that flags malformed framing, resets, and resource-exhaustion indicators.
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find events	HTTP/2 attacks are operationally visible through unusual network and service behavior.
Recommendation — Continuously monitor network services for protocol abuse and abnormal load patterns.
OWASP ASVS	V4 — API and Web Service	HTTP/2 is a web-service transport layer whose abuse affects request handling and service availability.
Recommendation — Validate service-layer request handling and enforce limits that prevent transport abuse.
OWASP API Security Top 10	API4 — Unrestricted Resource Consumption	HTTP/2 flooding and expensive framing directly target service resource exhaustion.
Recommendation — Cap resource use per client and per connection to stop protocol-driven exhaustion.

Practitioner Guidance

What to verify: Confirm that your reverse proxy, load balancer, and application server enforce independent HTTP/2 limits for streams, headers, and connection reuse. A single tuned component is not enough if another layer forwards traffic without equivalent protections.

What to measure: Track stream reset rates, concurrent stream counts, header parsing latency, and connection churn. Those signals usually tell you more about protocol abuse than generic traffic volume does.

Decision rule: If a service is internet-facing and HTTP/2 is enabled, treat protocol-level rate limiting and upstream shielding as baseline controls, not optional hardening.

Practitioner takeaway: The key question is not whether HTTP/2 is “secure,” but whether your stack can reject abusive protocol behavior cheaply enough to preserve availability under load.