What are the signs that an HTTP/2 stack is vulnerable to CONTINUATION Flood attacks?

Common signs include rising CPU usage during ordinary request volume, growing memory consumption tied to header processing, slow responses across unrelated requests, and crashes that point to out of memory conditions. If a service becomes unstable when handling a small number of malformed HTTP/2 requests, that is a strong indicator the implementation lacks sufficient framing limits.

What makes CONTINUATION Flood susceptibility visible in an HTTP/2 stack

CONTINUATION Flood weakness is usually visible as disproportionate work during header processing, not as a clean service outage from a single request. A stack that is sensitive to this class of abuse will often spend too much CPU and memory assembling or validating header blocks, and may become sluggish even when overall traffic looks modest. The key signal is that ordinary request volume causes outsized resource consumption, which means the implementation is doing too much stateful work before it has enforced a useful limit. For protocol context, the MITRE ATT&CK Enterprise Matrix is not a protocol reference, but it remains useful for thinking about how abuse of a service path can translate into broader availability impact.

Practitioners often miss this because the application layer still appears functional at first, while the transport and parsing layers are quietly accumulating pressure. In practice, many security teams encounter the weakness only after a burst of malformed HTTP/2 traffic has already forced a reset, timeout, or crash.

How the failure shows up during real HTTP/2 processing

The vulnerable behaviour is rooted in how the stack handles HTTP/2 header blocks. CONTINUATION frames allow a header sequence to span multiple frames, and a weak implementation may keep accepting or buffering those frames for too long before applying limits. That creates a path where an attacker can force repeated parsing, state tracking, or memory allocation with very little legitimate workload. In healthy implementations, the decoder should stop early when frame counts, header sizes, or stream state become unreasonable. When those checks are missing or deferred, the server may keep consuming resources while waiting for a header block to finish.

In practice, defenders should look for a pattern rather than a single symptom:

resource growth that tracks malformed header traffic more than normal request concurrency
response latency that spreads to unrelated requests because worker threads or event loops are saturated
retries, stream resets, or protocol errors that appear before the application logic is reached
process restarts or out of memory conditions after only a small amount of abnormal input

These signs matter because they point to an enforcement gap in the HTTP/2 parser, not just a transient performance problem. The most useful external reference for the protocol mechanics is the HTTP/2 specification in RFC 9113, which defines how frames, streams, and header blocks are supposed to behave. Where stacks break down, they usually fail to impose practical bounds on header continuation handling, or they do so too late to prevent resource exhaustion. The guidance stops being reliable when the implementation offloads parsing to shared workers without isolating malformed streams.

When the pattern is a genuine vulnerability instead of ordinary load

Tighter protocol enforcement often increases rejection rates for odd traffic, so operators must balance resilience against compatibility with intermediaries and clients that behave badly. The difference between a vulnerable stack and a merely busy one is usually whether small volumes of malformed HTTP/2 input can trigger disproportionate resource use.

One useful distinction is whether the pressure is repeatable and input-specific. If the issue appears only under broad traffic spikes, it is more likely a capacity problem. If it appears when a small number of crafted requests create outsized CPU, memory, or connection churn, the implementation may be missing a hard boundary in its framing logic. Another edge case is that some reverse proxies or load balancers absorb the attack surface before the origin sees it, so the origin server may look healthy even though the front door is already burning resources. Different vendors vary in how they cap continuation chains, so there is not a single consensus on the exact threshold that proves safety; the practical test is whether the parser rejects abuse before state growth becomes material.

For operational resilience context, CISA cyber threat advisories help teams track broader exploitation patterns and service-impacting weaknesses, even when the issue itself is protocol-specific. In this class of problem, the important clue is not just that the service is slow, but that the slowdown is reproducible with malformed HTTP/2 traffic that should have been constrained earlier.

Risk and Threat Considerations

CONTINUATION Flood weakness is an availability risk first, but it can also become an operational resilience problem when the parser, worker pool, or memory allocator is forced into excessive churn. The exposure is greatest in edge services, reverse proxies, and API gateways that terminate large amounts of HTTP/2 traffic and must defend themselves before forwarding requests downstream.

Failure mechanism: An attacker sends carefully structured HTTP/2 frames that keep header processing alive long enough to consume CPU, allocate memory, or pin connection state. The abuse works when the implementation delays enforcement of frame or header limits, or when continuation handling lets a small number of streams create disproportionate parsing work.

Impact: The service may slow down, stop accepting new connections, reset streams, crash, or trigger failover conditions that affect unrelated users. In severe cases, the vulnerable parser becomes an availability chokepoint for the entire front-end tier.

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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	8 — Audit Log Management	HTTP/2 flood symptoms are often first seen in logs and telemetry.
	13 — Network Monitoring and Defense	Detection depends on observing abnormal HTTP/2 frame patterns at the network edge.
Recommendation — Correlate parser errors, resets, and resource spikes to distinguish abuse from normal load. Inspect edge traffic for malformed continuation chains and block abusive request patterns early.
NIST CSF 2.0	PR.PT — Protective Technology	The issue is a protocol-handling weakness that should be bounded by protective controls.
Recommendation — Enforce protocol limits at the edge to prevent malformed HTTP/2 traffic from exhausting resources.
MITRE ATT&CK	T1499 — Endpoint Denial of Service	CONTINUATION Flood is an availability attack pattern that exhausts service resources.
Recommendation — Map repeated parser exhaustion to denial-of-service detection and alert on disproportionate resource use.

Practitioner Guidance

What to verify: Confirm whether your edge components, proxies, and origin services all enforce practical limits on HTTP/2 frame sequences, header size, and stream state before allocating substantial resources. A stack is not trustworthy simply because it handles normal requests correctly; it must also reject malformed continuation patterns without meaningful resource growth.

What to prioritize: Treat repeatable CPU or memory spikes from a small amount of crafted traffic as a protocol-handling defect, not a generic performance issue. The immediate question is whether the weak point sits in the parser, the load balancer, or the origin, because remediation differs depending on where the continuation chain is being accepted.

Practitioner takeaway: The most important judgement is whether the service fails closed on malformed HTTP/2 input, because if it does not, availability problems will usually appear before anyone sees a clean protocol error.