CVE-2024-31309

What it actually does

Apache Traffic Server versions 8.0.0 through 8.1.9 and 9.0.0 through 9.2.3 insufficiently limit abusive HTTP/2 CONTINUATION frame sequences. An unauthenticated remote client can send excessive CONTINUATION frames, typically as part of an unfinished or fragmented header block, causing ATS to spend disproportionate CPU, memory, and connection-handling resources processing HTTP/2 state. The impact is denial of service: degraded proxy/cache performance, worker resource exhaustion, connection saturation, and potential service unavailability. The flaw does not provide code execution, data theft, or privilege escalation by itself.

Why it matters to the business

Organizations using Apache Traffic Server as an edge proxy, reverse proxy, cache, or traffic gateway can experience customer-facing outages or severe latency if exposed HTTP/2 listeners are targeted. Because the attack can be performed remotely and the EPSS score is very high, internet-facing deployments should be treated as high priority even though this issue is not currently listed in CISA KEV and no ransomware use is reported. Disruption may affect web availability, API availability, content delivery, downstream application reachability, and incident response workload.

How an attack unfolds

An attacker first identifies an Apache Traffic Server endpoint that accepts HTTP/2, usually over TLS with ALPN negotiation for h2 or on a cleartext HTTP/2-enabled listener. The attacker then opens one or more HTTP/2 connections and sends HEADERS frames followed by a high volume of CONTINUATION frames, often delaying or omitting the END_HEADERS condition that would normally complete the header block. Vulnerable ATS versions continue processing the excessive continuation sequence and consume server resources. By repeating this across multiple streams or connections, the attacker can drive CPU, memory, and connection pressure high enough to slow or interrupt legitimate traffic. The attack does not require authentication and may leave limited application-layer evidence because it occurs at the HTTP/2 framing layer rather than as normal HTTP requests.

How to fix it

Upgrade Apache Traffic Server to a fixed release: 8.1.10 or later for the 8.1.x branch, or 9.2.4 or later for the 9.2.x branch. Source builds should include the upstream fix commit 90fbf13db0858cef0e0a094f445d846b60a4c1ef or a later commit containing the same fix. After upgrading, configure the new control proxy.config.http2.max_continuation_frames_per_minute to limit excessive HTTP/2 CONTINUATION frames per minute according to expected production traffic patterns. If immediate upgrade is not possible, reduce exposure by disabling HTTP/2 where operationally acceptable, restricting access to trusted networks, placing a patched HTTP/2-aware load balancer or WAF in front of ATS, rate-limiting abusive clients, and monitoring ATS resource utilization closely. Mitigations should be considered temporary; patching remains the primary fix.

How to confirm the fix worked

Confirm deployed Apache Traffic Server versions are not in the affected ranges 8.0.0-8.1.9 or 9.0.0-9.2.3. Validate package, container image, and source build provenance to ensure the running binary is 8.1.10, 9.2.4, later, or includes commit 90fbf13db0858cef0e0a094f445d846b60a4c1ef. Review records.config or effective runtime configuration to confirm proxy.config.http2.max_continuation_frames_per_minute is present and set to an appropriate non-default limit if used. Test externally that HTTP/2 exposure matches policy, and verify that expected services remain available after upgrade. In controlled testing only, use an HTTP/2 frame-level test tool to send excessive CONTINUATION frames and confirm ATS rejects, limits, or closes the abusive connection without abnormal CPU, memory, or connection growth.

Typical attack path

1. Discover an internet-facing or reachable Apache Traffic Server deployment that supports HTTP/2.
2. Confirm HTTP/2 negotiation is accepted, commonly through TLS ALPN h2 or an HTTP/2-capable listener.
3. Open HTTP/2 connections to the proxy or cache service.
4. Send HEADERS frames followed by excessive CONTINUATION frames, especially without promptly ending the header block.
5. Repeat the frame pattern across multiple streams or connections to increase resource consumption.
6. Maintain pressure until ATS worker resources, connection capacity, CPU, or memory are degraded enough to deny or slow legitimate service.

How to detect it

Look for evidence of availability degradation correlated with abnormal HTTP/2 traffic rather than normal HTTP request volume. Useful sources include Apache Traffic Server error logs and diagnostic logs, proxy access logs, system metrics, load balancer telemetry, NetFlow or packet captures, IDS/NDR HTTP/2 protocol events, TLS ALPN negotiation logs, and host monitoring for the traffic_server process. Indicators include sudden increases in HTTP/2 connections or streams, many connections that negotiate h2 but do not complete normal requests, high volumes of CONTINUATION frames, repeated header blocks without END_HEADERS, elevated CPU or memory in traffic_server, connection churn, client resets, increased 408/429/5xx responses, and latency spikes without a matching increase in completed requests. If packet capture or NDR metadata is available, search for repeated HTTP/2 frame type 0x09 CONTINUATION frames, especially sequences where the END_HEADERS flag is absent for an unusually long frame chain. Because exploitation may not create normal URL-level artifacts, absence of suspicious URLs in access logs does not rule out attempted exploitation.

• HTTP/2 CONTINUATION frame flood
• HTTP/2 frame type 0x09
• CONTINUATION frames without END_HEADERS
• END_HEADERS flag absent
• ALPN h2
• traffic_server high CPU
• traffic_server high memory
• proxy.config.http2.max_continuation_frames_per_minute
• records.config
• error.log
• diags.log

What your security team should do

• Inventory all Apache Traffic Server deployments, including edge proxies, reverse proxies, caching layers, containers, and appliance-like packaged deployments.
• Prioritize internet-facing ATS instances that allow HTTP/2, because the vulnerability is remotely reachable and has a very high EPSS probability score.
• Upgrade affected deployments to ATS 8.1.10, 9.2.4, or later; for source builds, verify inclusion of commit 90fbf13db0858cef0e0a094f445d846b60a4c1ef.
• Set and tune proxy.config.http2.max_continuation_frames_per_minute after upgrade to reduce tolerance for abusive HTTP/2 continuation behavior.
• Temporarily disable HTTP/2 or restrict access if patching cannot be completed quickly and business impact is acceptable.
• Add monitoring for spikes in HTTP/2 connection counts, incomplete header blocks, connection resets, worker CPU, memory pressure, accept queue saturation, and 5xx/latency anomalies.
• Coordinate with network and CDN/WAF teams to rate-limit suspicious HTTP/2 clients and block sources generating abnormal frame-level behavior.
• Review historical telemetry since publication for signs of resource-exhaustion events that align with unusual HTTP/2 traffic patterns.