What attacks target HTTP/2?

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.

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.

Related resources from NHI Mgmt Group

• How can organizations counter AI-driven cyber attacks?
• Who should own identity risk when attacks target both people and third-party access?
• How should security teams handle vishing attacks that target SaaS support workflows?
• Why do supply-chain attacks increasingly target secrets instead of just code integrity?