CVE-2024-24549

What it actually does

CVE-2024-24549 is an Apache Tomcat HTTP/2 denial-of-service flaw caused by improper handling of requests whose headers exceed configured limits. In vulnerable Tomcat versions, when an HTTP/2 request exceeds header size or header count limits, Tomcat does not reset the affected HTTP/2 stream until after all headers have been processed. A remote unauthenticated client can therefore force the server to spend CPU, memory, and connection/worker resources parsing oversized or excessive HTTP/2 header blocks that should have been rejected earlier. The impact is availability only: the flaw does not directly allow code execution, data theft, or privilege escalation, but it can degrade or interrupt application service.

Why it matters to the business

Successful exploitation can make Tomcat-hosted applications slow, unstable, or unavailable, affecting customer-facing services, APIs, internal portals, and systems that depend on those applications. Because exploitation is network-accessible, requires no authentication, and has a high availability impact, internet-facing Tomcat services with HTTP/2 enabled should be prioritized even though the issue is not currently listed in CISA KEV and no mature public exploit is indicated in the provided data. The EPSS score is moderate, so broad opportunistic probing is plausible, especially for exposed web services that reveal Tomcat or HTTP/2 support.

How an attack unfolds

An attacker identifies a Tomcat service that accepts HTTP/2 connections, typically over TLS using ALPN negotiation or through a front-end that passes HTTP/2 to Tomcat. The attacker then opens one or more HTTP/2 connections and sends requests with header blocks that exceed Tomcat's configured header size or header count limits. On vulnerable versions, Tomcat recognizes that the stream violates configured limits but does not reset the stream immediately; instead, it continues processing the full header set. By repeating this across many streams or connections, the attacker consumes server CPU, memory, and request-processing capacity. The application may begin returning errors, rejecting legitimate requests, exhausting thread pools, or becoming unreachable until traffic stops, connections are dropped, or the service is restarted or patched.

How to fix it

Upgrade Apache Tomcat to a fixed version: 11.0.0-M17 or later for the 11.x milestone line, 10.1.19 or later for 10.1.x, 9.0.86 or later for 9.0.x, and 8.5.99 or later for 8.5.x. The upstream Git fix is reflected in commit 542c35ae834fb29616b184a0e4276a5b7f8542de. If Tomcat is supplied by an operating-system package or embedded in a vendor product, apply the vendor-provided update rather than only replacing standalone files. Review the listed distribution packages where applicable, including doctrine fixed in 2.4.8-2, php-doctrine-annotations fixed in 1.2.7-1build1 for Ubuntu 16.04 LTS and 1.5.0really1.2.7-1 for Ubuntu 18.04 LTS, php-doctrine-cache fixed in 1.6.0-1ubuntu2, and php-doctrine-common fixed in 2.4.3-1ubuntu1, while recognizing that the primary vulnerable runtime described by this CVE is Apache Tomcat. If immediate upgrade is not possible, reduce exposure by disabling HTTP/2 on Tomcat connectors where operationally acceptable, terminating HTTP/2 at a patched reverse proxy that enforces strict header limits, applying WAF or load-balancer rules for excessive header size/count, rate-limiting suspicious clients, and ensuring connection/request limits are tuned to prevent resource exhaustion.

How to confirm the fix worked

Confirm the deployed Tomcat version is at or above the fixed release for the running branch using the startup banner, `catalina.sh version`, package manager metadata, container image digest, or the Tomcat `ServerInfo.properties`/JAR manifest. Review `server.xml` and deployment configuration for HTTP/2 enablement, especially `org.apache.coyote.http2.Http2Protocol` configured as an `UpgradeProtocol` on connectors. Verify that all application images, embedded Tomcat distributions, and vendor appliances have been rebuilt or updated, not only the base host package. In a non-production environment, send controlled HTTP/2 requests with headers that exceed configured size/count limits and confirm the server rejects or resets the stream promptly without sustained CPU, memory, or thread growth. After deployment, monitor for reduced occurrences of HTTP/2 header-limit errors, connection exhaustion, elevated request latency, and Tomcat restarts under malformed-header traffic.

Typical attack path

1. Discover a web endpoint backed by Apache Tomcat with HTTP/2 enabled.
2. Negotiate an HTTP/2 connection to the target service.
3. Send HTTP/2 requests containing oversized headers or an excessive number of headers that exceed configured Tomcat limits.
4. Repeat the requests across multiple streams and connections to amplify parsing overhead.
5. Consume Tomcat processing resources, causing latency, failed requests, connection resets, or application outage.

How to detect it

To determine whether exploitation has already occurred, review Tomcat, reverse proxy, load balancer, WAF, and infrastructure telemetry for periods of unexplained availability degradation that align with bursts of HTTP/2 traffic containing unusually large headers or many headers. In Tomcat logs, look for repeated HTTP/2 parser or stream errors indicating header size or header count limits were exceeded, especially when clustered by source IP, user agent absence, high request rate, or many streams over few connections. In proxy and WAF logs, search for HTTP/2 requests returning 400, 431, 503, connection reset, or upstream timeout responses with large request-header byte counts. In system and JVM telemetry, correlate suspicious traffic with elevated CPU, heap pressure, garbage collection spikes, thread pool saturation, high open connection counts, or Tomcat restarts. Because this is a denial-of-service issue, the most reliable evidence is behavioral correlation between malformed HTTP/2 request bursts and resource exhaustion rather than creation of persistent files or post-exploitation artifacts.

• The HTTP header size exceeded the configured limit
• The HTTP header count exceeded the configured limit
• org.apache.coyote.http2.Http2Parser
• org.apache.coyote.http2.Http2UpgradeHandler
• HTTP/2 stream was reset
• header size exceeded
• header count exceeded
• request header is too large
• HTTP 431
• Request Header Fields Too Large
• h2
• org.apache.coyote.http2.Http2Protocol

What your security team should do

• Inventory all Apache Tomcat deployments, including container images, embedded application servers, vendor products, and externally exposed services.
• Prioritize internet-facing or partner-facing Tomcat services with HTTP/2 enabled, especially those running 11.0.0-M1 through 11.0.0-M16, 10.1.0-M1 through 10.1.18, 9.0.0-M1 through 9.0.85, or 8.5.0 through 8.5.98.
• Upgrade to Tomcat 11.0.0-M17, 10.1.19, 9.0.86, 8.5.99, or later according to the deployed branch.
• Where patching is delayed, disable HTTP/2 on vulnerable Tomcat connectors or place the service behind a patched proxy/load balancer that terminates HTTP/2 and enforces conservative header limits.
• Add monitoring and alerting for bursts of HTTP/2 header-limit violations, abnormal 400/431 responses, connection resets, elevated Tomcat CPU, memory pressure, and thread-pool saturation.
• Review historical web, proxy, WAF, and Tomcat logs for evidence of repeated oversized-header or excessive-header HTTP/2 traffic from the same sources.
• Include this issue in vulnerability management SLAs as a high-availability-risk service exposure even though it is not currently CISA KEV-listed.