What happens when HTTP/2 CONTINUATION Flood protection is missing from a web service?

Without protection, an attacker can send a single request that never terminates its header block and forces the server to keep processing CONTINUATION frames. The result can be degraded throughput, request latency for other users, service hangs, or a crash. In practice, the failure mode is an availability loss caused by unbounded header parsing.

How CONTINUATION Flood Protection Fails and Why the Impact Is Broad

HTTP/2 CONTINUATION flood protection exists to stop a peer from keeping a header block open indefinitely and consuming parser resources without completing the request. When that guardrail is missing, the service can be forced into repeated header-processing work that blocks normal traffic, increases queueing, and can destabilise worker processes. For a public-facing web service, that is not a narrow protocol bug, it is an availability problem that can affect every user sharing the same front end.

The practical risk is that the attacker does not need high bandwidth or a large number of connections to create pressure. A single well-formed stream can hold state open while the server keeps accepting CONTINUATION frames, which means the damage often shows up as slower responses long before a full outage. The NIST Cybersecurity Framework 2.0 is relevant here because the failure sits squarely in resilience and service availability, not just protocol correctness. In practice, many operators notice the problem first as unexplained latency spikes rather than an obvious attack signature.

How the Attack Pattern Plays Out in Production

HTTP/2 allows a header block to be split across an initial HEADERS frame and one or more CONTINUATION frames. That design is safe only when the implementation enforces sane limits on header-block length, frame sequencing, and parser work per connection. If CONTINUATION flood protection is missing, the parser may continue allocating CPU time and state to a request that never completes, while other requests wait behind it.

In production, the degradation usually follows a few recognisable stages. First, one or more connections consume disproportionate parsing effort. Next, worker threads or event-loop cycles are spent servicing the incomplete header block rather than new requests. Then the service may begin to queue, time out, or reset connections under pressure. If the implementation also couples header parsing to memory growth or lock contention, the event can escalate from slowdowns to process termination.

Long-lived incomplete streams can pin resources even when traffic volume looks low.
Shared front ends are especially exposed because one abusive client can affect many normal users.
Reverse proxies, load balancers, and application servers may fail differently, which complicates diagnosis.

The NIST SP 800-53 Rev 5 Security and Privacy Controls is useful as a control reference because the issue maps to availability protection, service resilience, and defensive monitoring of externally exposed components. Where implementations are robust, they cap header-block processing, bound parser effort, and terminate abusive streams early. Where they are not, the guidance breaks down when a single connection can monopolise enough processing to affect the entire service tier.

When the Standard Answer Stops Being Enough

Tighter protocol enforcement often improves resilience but can also increase false positives and operational tuning effort, so teams have to balance strictness against legitimate large-header traffic. The cleanest implementations do not assume every large request is malicious; they differentiate normal header growth from a request that refuses to terminate.

One important edge case is that the visible symptom may be at a different layer from the bug. A proxy may absorb the abuse while the application appears healthy, or the application may be fine while the edge device collapses first. Another edge case is that shared infrastructure can turn a single implementation weakness into a platform-wide outage, especially when many virtual hosts or tenants rely on the same HTTP/2 stack.

There is also a boundary condition around observability. If teams only watch for crashes, they can miss the earlier signal of parser starvation, rising request latency, or uneven connection handling. Good practice is to treat any sustained growth in incomplete HTTP/2 header processing as an operational warning, not just a protocol anomaly. The NIST SP 800-53 Rev 5 Security and Privacy Controls is helpful here because it supports the broader idea that externally exposed services need bounded resource use, not merely functional correctness.

Standards & Framework Alignment

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

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-5 — Network Integrity is Protected	HTTP/2 flood protection preserves service integrity against abusive connection use.
	DE.CM-1 — Monitoring for Anomalies and Events	Missing protection is detectable through abnormal header-processing and latency patterns.
	RS.MI-3 — Mitigation is Applied	Mitigation means stopping abusive streams before they consume excessive resources.
Recommendation — Enforce connection-level limits to prevent one stream from degrading service availability. Monitor parser and latency anomalies to spot CONTINUATION flood attempts early. Terminate abusive HTTP/2 streams before they can exhaust shared worker capacity.
CIS Controls v8	8.2 — Audit Log Management	Logs and telemetry are needed to identify repeated incomplete header-block processing.
	13.1 — Network Monitoring and Defense	The attack is network-exposed and benefits from monitoring at the service edge.
	4.1 — Establish and Maintain a Secure Configuration Process	The issue is prevented by securely configured protocol limits and parser safeguards.
Recommendation — Retain request and protocol logs that show abusive HTTP/2 frame patterns. Inspect edge traffic for abnormal HTTP/2 frame sequencing and stream persistence. Set strict HTTP/2 limits for header blocks, frame counts, and parser resource use.
MITRE ATT&CK	T1499 — Endpoint Denial of Service	The flood consumes processing resources until the service degrades or fails.
	T1498 — Network Denial of Service	The abuse is delivered over network traffic against an exposed web service.
Recommendation — Map repeated CONTINUATION abuse to T1499 and tune detections for resource exhaustion. Treat high-cost HTTP/2 request patterns as network DoS activity and block sources quickly.

Practitioner Guidance

What to prioritise: Bound header-block processing first. If the parser can be kept busy indefinitely by one stream, transport-layer hardening will not rescue the service once saturation starts.

What to verify: Confirm that limits exist for incomplete header blocks, total CONTINUATION frames, per-connection parsing time, and memory growth. If any one of those is unlimited, the control is still fragile.

Decision rule: Treat rising latency on a small number of HTTP/2 connections as a potential abuse signal when it is paired with unfinished header blocks or repeated CONTINUATION activity, even if there is no crash yet.

What good looks like: The service rejects abusive streams early, preserves throughput for unrelated traffic, and produces logs or metrics that show parser exhaustion attempts instead of silently degrading.

Practitioner takeaway: The real test is not whether the service can parse HTTP/2, but whether it can stop one incomplete request from monopolising shared availability.