CVE-2025-53506: Apache Tomcat DoS Vulnerability

CVE-2025-53506 Overview

CVE-2025-53506 is an uncontrolled resource consumption vulnerability in Apache Tomcat's HTTP/2 implementation. The flaw allows a remote, unauthenticated attacker to exhaust server resources when an HTTP/2 client refuses to acknowledge the server's initial SETTINGS frame that reduces the maximum permitted concurrent streams. Affected versions span Apache Tomcat 11.0.0-M1 through 11.0.8, 10.1.0-M1 through 10.1.42, and 9.0.0.M1 through 9.0.106. End-of-life versions in the 8.5.x branch (8.5.0 through 8.5.100) are also known to be affected. The Apache Software Foundation released fixes in versions 11.0.9, 10.1.43, and 9.0.107.

Critical Impact

A remote attacker can trigger denial of service against Apache Tomcat servers using HTTP/2 by opening connections that ignore server stream-limit settings, exhausting server memory and threads.

Affected Products

• Apache Tomcat 11.0.0-M1 through 11.0.8
• Apache Tomcat 10.1.0-M1 through 10.1.42
• Apache Tomcat 9.0.0.M1 through 9.0.106 (and EOL 8.5.0 through 8.5.100)

Discovery Timeline

• 2025-07-10 - CVE-2025-53506 published to NVD
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2025-53506

Vulnerability Analysis

The vulnerability resides in Apache Tomcat's HTTP/2 connection handling logic. HTTP/2 allows a server to advertise the maximum number of concurrent streams a client may open by sending a SETTINGS frame with the SETTINGS_MAX_CONCURRENT_STREAMS parameter. When Tomcat lowers this limit mid-connection, the protocol expects the client to acknowledge the new settings before opening additional streams beyond the new ceiling. The flaw is categorized as Uncontrolled Resource Consumption under [CWE-400]. The EPSS score of this issue places it in the higher exploit-likelihood tier compared to most published CVEs, reflecting the simplicity of triggering the condition over the network.

Root Cause

Tomcat fails to enforce the reduced stream limit until the client acknowledges the updated SETTINGS frame. A malicious client can deliberately withhold the acknowledgment while continuing to open new streams under the previous, higher limit. Each open stream consumes server-side memory, request-processing threads, and tracking state. Without strict enforcement of the limit during the unacknowledged window, the server cannot apply backpressure on misbehaving clients.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker establishes an HTTP/2 connection to a vulnerable Tomcat instance, receives the server's SETTINGS frame, and refuses to send the corresponding SETTINGS ACK frame. The attacker then issues a large number of concurrent HEADERS frames to open streams beyond the reduced limit. Repeating this across multiple connections amplifies resource exhaustion, degrading or halting service for legitimate users. The vulnerability is described in prose only because no verified public exploit code has been released. See the Apache Security Mailing List Update for the official advisory.

Detection Methods for CVE-2025-53506

Indicators of Compromise

• Sustained growth in active HTTP/2 stream counts on a single connection without corresponding completion of requests.
• HTTP/2 connections where the client receives a SETTINGS frame from the server but never sends a SETTINGS ACK frame.
• Spikes in JVM heap usage, request-processor thread saturation, or OutOfMemoryError events in catalina.out.

Detection Strategies

• Inspect Tomcat access logs and HTTP/2 protocol logs for connections that open large numbers of concurrent streams from a single client IP.
• Use a reverse proxy or web application firewall capable of HTTP/2 protocol introspection to flag missing SETTINGS acknowledgments.
• Correlate connection-level anomalies with JVM metrics such as thread pool saturation and garbage collection pressure.

Monitoring Recommendations

• Enable Tomcat's HTTP/2 debug logging in staging to baseline normal stream and settings-frame behavior before tuning production alerts.
• Export Tomcat connector metrics via JMX or Micrometer and alert on abnormal currentThreadsBusy and active connection counts.
• Monitor upstream load balancers and CDN edges for HTTP/2 connection anomalies that may precede backend resource exhaustion.

How to Mitigate CVE-2025-53506

Immediate Actions Required

• Upgrade Apache Tomcat to version 11.0.9, 10.1.43, or 9.0.107 as soon as feasible.
• Inventory all Tomcat deployments, including embedded instances in Spring Boot and other frameworks, to confirm patch coverage.
• Restrict direct internet exposure of Tomcat connectors behind a hardened reverse proxy where possible.

Patch Information

The Apache Tomcat project addressed CVE-2025-53506 by enforcing the reduced concurrent stream limit immediately upon sending the updated SETTINGS frame, rather than waiting for client acknowledgment. Fixed releases are Apache Tomcat 11.0.9, 10.1.43, and 9.0.107. Refer to the Apache Security Mailing List Update, the OpenWall OSS-Security Notice, and the Debian LTS Security Announcement for distribution-specific guidance.

Workarounds

• Disable the HTTP/2 upgrade protocol on Tomcat connectors and serve traffic over HTTP/1.1 until patching is complete.
• Place Tomcat behind a reverse proxy such as Apache HTTPD or NGINX that terminates HTTP/2 and applies its own stream and connection limits.
• Lower the maxConcurrentStreams, maxConcurrentStreamExecution, and connection timeout values on the HTTP/2 UpgradeProtocol configuration to reduce blast radius.

# Example: temporarily disable HTTP/2 on a Tomcat connector in server.xml
# Remove or comment out the UpgradeProtocol element until patched
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           SSLEnabled="true" maxThreads="200" scheme="https" secure="true">
    <!-- <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
                       maxConcurrentStreams="50"
                       maxConcurrentStreamExecution="20" /> -->
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/keystore.jks"
                     type="RSA" />
    </SSLHostConfig>
</Connector>