CVE-2024-34750

What it actually does

This vulnerability is a network-exploitable denial-of-service flaw in Apache Tomcat's HTTP/2 handling. When Tomcat processes certain HTTP/2 streams containing excessive HTTP headers, it can incorrectly track the number of active streams on a connection. That miscount may cause Tomcat to apply an inappropriate infinite timeout, allowing connections that should have been closed to remain open indefinitely. An unauthenticated remote attacker can consume server connection, thread, memory, or related HTTP/2 processing resources until legitimate users experience degraded service or outage. The flaw affects Apache Tomcat 11.0.0-M1 through 11.0.0-M20, 10.1.0-M1 through 10.1.24, and 9.0.0-M1 through 9.0.89.

Why it matters to the business

Successful exploitation can make Tomcat-hosted applications slow or unavailable without requiring valid credentials. For internet-facing services, this can cause customer-facing outages, failed transactions, service-level objective violations, incident response costs, and potential cascading impact to dependent applications. Although there is no known CISA KEV listing or known ransomware association for this vulnerability, it is remotely exploitable with low attack complexity and has high availability impact, so exposed Tomcat services should be upgraded or mitigated promptly.

How an attack unfolds

An attacker identifies a Tomcat service with HTTP/2 enabled and running an affected version. They then open one or more HTTP/2 connections and send crafted streams with excessive headers or header patterns that trigger Tomcat's exceptional-condition handling defect. Instead of closing the problematic stream or connection correctly, Tomcat miscounts active HTTP/2 streams and may leave the connection under an infinite timeout. By repeating this across many streams or connections, the attacker pins server-side resources and gradually reduces the capacity available for legitimate traffic. The attack does not require authentication, user interaction, or application-specific functionality beyond reachable HTTP/2 support.

How to fix it

Upgrade Apache Tomcat to a fixed release: Tomcat 11.0.0-M21 or later, Tomcat 10.1.25 or later, or Tomcat 9.0.90 or later. For source-based deployments, ensure the fix corresponding to apache/tomcat commit 65977c7d1da9b6016e2b19de06c3be7373f40859 is included. If immediate upgrade is not possible, reduce exposure by disabling HTTP/2 where operationally acceptable, placing Tomcat behind a reverse proxy or load balancer with strict HTTP/2 header and connection limits, enforcing maximum header sizes and request limits, limiting long-lived connections, applying rate limits per source IP, and restricting access to Tomcat services that do not need to be internet-facing. These mitigations reduce attack surface but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm the running Tomcat version is not in the affected ranges: 11.0.0-M1 through 11.0.0-M20, 10.1.0-M1 through 10.1.24, or 9.0.0-M1 through 9.0.89. Validate that deployed artifacts, container images, packages, and embedded Tomcat dependencies have been rebuilt or updated to Tomcat 11.0.0-M21, 10.1.25, 9.0.90, or later. If Tomcat was built from source, verify the presence of commit 65977c7d1da9b6016e2b19de06c3be7373f40859 or an equivalent patch. Review server configuration to determine whether HTTP/2 is enabled on connectors or front-end proxies. After remediation, perform controlled HTTP/2 stress testing with large header scenarios to confirm the server closes invalid streams/connections normally and resource usage returns to baseline. Monitor connection counts, request latency, thread pool utilization, heap usage, and HTTP/2 error handling before and after the change.

Typical attack path

1. Scan for reachable web applications or APIs served by Apache Tomcat with HTTP/2 enabled.
2. Confirm the target appears to be running an affected Tomcat version or behaves like a vulnerable HTTP/2 endpoint.
3. Open HTTP/2 connections to the target service.
4. Send streams containing excessive HTTP headers or malformed/high-volume header conditions that trigger improper exception handling.
5. Keep connections open while Tomcat incorrectly applies an infinite timeout and miscounts active streams.
6. Repeat the process to consume connection, thread, memory, or HTTP/2 processing capacity.
7. Cause legitimate user requests to slow down, fail, or time out.

How to detect it

To assess possible prior exploitation, review web server, Tomcat, reverse proxy, load balancer, and network telemetry for unusual HTTP/2 behavior. Focus on periods with unexplained availability degradation, spikes in open connections, thread pool exhaustion, memory pressure, request timeouts, or elevated 5xx responses. Useful log sources include Tomcat access logs, Catalina logs, application logs, reverse proxy logs from NGINX/Apache/Envoy/HAProxy, load balancer logs, WAF logs, NetFlow, packet captures, and infrastructure metrics. Look for repeated HTTP/2 requests from the same source or small source set, unusually large request headers, many streams opened without normal request completion, long-lived idle connections, header-size exceptions, stream reset anomalies, and request bursts followed by increased latency or service unavailability. Because this vulnerability primarily causes denial of service and does not inherently create files or execute commands, host-based forensic artifacts may be limited to resource-exhaustion symptoms rather than persistent compromise indicators.

• HTTP/2
• h2
• too many headers
• excessive headers
• header size
• maxHeader
• HeaderTooLarge
• ConnectionTimeout
• connection timeout
• stream reset
• RST_STREAM
• GOAWAY
• too many active streams
• active HTTP/2 streams
• org.apache.coyote.http2
• Http2UpgradeHandler
• StreamException
• ConnectionException
• java.lang.OutOfMemoryError
• java.util.concurrent.RejectedExecutionException
• The connector has been paused
• Failed to complete processing of a request
• 503
• 504

What your security team should do

• Inventory all Apache Tomcat instances, including embedded Tomcat in Java applications, container images, vendor appliances, and development or staging systems.
• Prioritize internet-facing Tomcat services with HTTP/2 enabled for immediate upgrade to 11.0.0-M21, 10.1.25, 9.0.90, or later.
• If upgrade cannot be completed quickly, temporarily disable HTTP/2 or enforce strict HTTP/2 header, stream, connection, and rate limits at the reverse proxy, load balancer, or ingress layer.
• Add monitoring and alerting for abnormal HTTP/2 connection duration, excessive header-related errors, elevated active connection counts, thread pool saturation, and unexplained increases in request latency or 5xx responses.
• Review logs and telemetry for signs of prior resource-exhaustion attempts, especially repeated HTTP/2 requests with large headers or many connections from a small number of source IPs.
• Ensure vulnerability scanners and software composition analysis tools detect affected Tomcat versions across packaged applications and source-built deployments.
• Document and test rollback plans before upgrading production Tomcat services, since availability-sensitive systems may require coordinated maintenance windows.