CVE-2025-53506

What it actually does

Apache Tomcat’s HTTP/2 handling could consume excessive server resources when a client failed to acknowledge the initial SETTINGS frame that lowers the allowed number of concurrent streams. By keeping the connection in a state where Tomcat has not received the expected SETTINGS acknowledgement, an attacker can cause Tomcat to permit or track more stream activity than intended, leading to uncontrolled memory, CPU, thread, or connection-state consumption. The impact is denial of service rather than code execution or data disclosure.

Why it matters to the business

A vulnerable Tomcat server with HTTP/2 enabled can be made slow or unavailable by a remote client, potentially disrupting web applications, APIs, customer portals, and dependent services. The issue is not currently listed in CISA KEV and has a relatively low EPSS score, but public awareness is established and denial-of-service flaws in internet-facing application servers can still be operationally significant. Organizations using Tomcat 9, 10.1, or 11 should treat exposed HTTP/2 endpoints as higher priority, especially where availability is critical.

How an attack unfolds

An attacker identifies an Apache Tomcat instance that supports HTTP/2 and runs an affected version. The attacker opens one or more HTTP/2 sessions and intentionally does not acknowledge Tomcat’s initial SETTINGS frame, particularly the setting that reduces the maximum concurrent stream limit. The attacker then maintains or repeats these connections to force Tomcat to retain HTTP/2 connection and stream state beyond the intended limits. At scale, this can exhaust server resources or degrade request handling for legitimate users. The technique is associated with HTTP/2 resource-exhaustion activity such as the MadeYouReset-style abuse pattern, where protocol-level behavior rather than application logic is used to disrupt service.

How to fix it

Upgrade Apache Tomcat to a fixed version: 11.0.9 or later for the 11.x branch, 10.1.43 or later for the 10.1.x branch, or 9.0.107 or later for the 9.x branch. If immediate upgrade is not possible, consider disabling HTTP/2 support on vulnerable Tomcat connectors, placing the service behind a reverse proxy or load balancer with strict HTTP/2 connection and stream limits, reducing idle and keep-alive timeouts, enforcing per-IP connection limits, and using rate limiting or DDoS protection for exposed endpoints. Mitigations should be treated as temporary until Tomcat is upgraded.

How to confirm the fix worked

Confirm the deployed Tomcat runtime version is 11.0.9+, 10.1.43+, or 9.0.107+. Verify that all application nodes, containers, base images, embedded Tomcat runtimes, and downstream packages have been rebuilt or redeployed with the fixed version. Check connector configuration to determine whether HTTP/2 is enabled; if HTTP/2 remains enabled, confirm protective limits are enforced at Tomcat or upstream proxy layers. From an external perspective, validate exposure by checking whether the service negotiates HTTP/2 via ALPN and whether the responding stack is Tomcat-backed. After remediation, monitor that abnormal HTTP/2 connection growth no longer causes elevated CPU, memory, connection counts, thread usage, or request latency.

Typical attack path

1. Scan for internet-facing services that advertise HTTP/2 and appear to be Apache Tomcat or Tomcat-backed applications.
2. Confirm that the target is running an affected Tomcat version: 11.0.0-M1 through 11.0.8, 10.1.0-M1 through 10.1.42, or 9.0.0.M1 through 9.0.106.
3. Establish HTTP/2 connections to the target service.
4. Withhold acknowledgement of Tomcat’s initial HTTP/2 SETTINGS frame that reduces the permitted concurrent streams.
5. Generate or maintain enough HTTP/2 connection and stream activity to consume Tomcat resources.
6. Repeat across multiple connections or source addresses until the application becomes slow, unstable, or unavailable.

How to detect it

To assess prior exploitation, review web server, reverse proxy, load balancer, WAF, and Tomcat logs for bursts of HTTP/2 traffic where clients open connections but do not complete expected SETTINGS acknowledgement behavior. Correlate these events with elevated CPU, heap usage, garbage collection pressure, thread pool saturation, connection count spikes, 5xx responses, increased request latency, application restarts, or out-of-memory conditions. Useful log sources include Tomcat catalina logs, access logs with protocol fields, reverse proxy HTTP/2 telemetry, load balancer connection metrics, WAF event logs, JVM metrics, garbage collection logs, container orchestration restart events, and network flow data. Look for repeated HTTP/2 sessions from the same source addresses or distributed sources, unusually long-lived idle or semi-active HTTP/2 connections, high rates of stream creation, GOAWAY/RST_STREAM activity, and time-correlated service degradation. Because the exploit may not create a unique application-layer payload, detection should focus on protocol anomalies and resource-exhaustion symptoms rather than request URIs alone.

• HTTP/2 SETTINGS ACK not received
• SETTINGS frame not acknowledged
• initial SETTINGS frame
• MAX_CONCURRENT_STREAMS
• too many active streams
• RST_STREAM
• GOAWAY
• org.apache.coyote.http2
• Http2UpgradeHandler
• ConnectionException
• StreamException
• OutOfMemoryError
• java.lang.OutOfMemoryError
• GC overhead limit exceeded
• unable to create new native thread
• RejectedExecutionException
• 503
• 504

What your security team should do

• Inventory all Apache Tomcat deployments, including container images, embedded application servers, vendor appliances, and packaged Java applications that bundle Tomcat.
• Prioritize upgrades for internet-facing Tomcat services and business-critical applications that have HTTP/2 enabled.
• Upgrade affected branches to Tomcat 11.0.9+, 10.1.43+, or 9.0.107+ and redeploy all dependent workloads.
• If patching is delayed, disable HTTP/2 or enforce strict HTTP/2 limits at reverse proxies, load balancers, WAFs, and edge services.
• Add monitoring for spikes in HTTP/2 connections, incomplete SETTINGS acknowledgements, excessive concurrent streams, connection resets, and abnormal Tomcat resource utilization.
• Review availability incident timelines since publication for unexplained Tomcat slowdowns, restarts, thread exhaustion, memory pressure, or HTTP/2 error bursts.
• Ensure operational runbooks include rapid HTTP/2 disablement or traffic filtering as an emergency mitigation for application-layer denial-of-service events.