Apache Tomcat 9.0: What's New, Release History & Support Lifecycle

What Is New in Apache Tomcat 9.0

What critical security vulnerabilities were fixed in Apache Tomcat 9.0?

The 9.0 branch has received patches for several high-impact CVEs that every production team should treat as mandatory upgrades. The most operationally dangerous are CVE-2025-24813 (critical RCE/information disclosure) and CVE-2024-56337 (high RCE), both of which require the Default Servlet to have writes enabled -- a non-default configuration, but one that some file-serving setups deliberately use.

CVE-2025-24813 exploited the partial PUT implementation: temporary files were named using the user-supplied path with separators replaced by dots, which allowed a carefully crafted PUT request to overlap with sensitive files in a parent upload directory. If writes were enabled and the attacker could also upload a serialized Java object via partial PUT, remote code execution was possible through deserialization. This was actively exploited in the wild within 30 hours of public disclosure.

• CVE-2025-24813 -- Critical RCE/information disclosure. Fixed in 9.0.99. Requires write-enabled Default Servlet.
• CVE-2024-56337 -- High RCE. Case-insensitive file system + write-enabled Default Servlet allows uploaded file to be treated as a JSP. Fixed in 9.0.99. Tomcat now automates the JVM configuration check at startup and blocks affected apps from starting if the JVM cannot be correctly hardened.
• CVE-2025-31651 -- Critical Authorization Bypass via malformed Rewrite rule. Fixed in 9.0.104.
• CVE-2025-31650 -- High DoS via invalid HTTP/2 priority header. Fixed in 9.0.104.
• CVE-2025-46701 -- High Authorization Bypass in the CGI Servlet. Fixed by refactoring to use the WebResources API.

Watch out for the CVE-2024-56337 startup behaviour change: if your deployment has a write-enabled Default Servlet and runs on a case-insensitive file system (Windows, macOS HFS+), Tomcat will now attempt to set the JVM system property sun.io.useCanonCaches to false automatically. If it cannot do so, the impacted web application will be prevented from starting. Plan for this before upgrading production Windows hosts.

How has TLS/SSL configuration changed in Apache Tomcat 9.0?

TLS configuration in the 9.0 branch has gone through the most significant structural evolution since the introduction of SSLHostConfig -- particularly around OCSP, cipher management, and the FFM (Foreign Function and Memory) OpenSSL integration that is being hardened to match the legacy Tomcat Native behaviour.

The most impactful change for upgraders is the separation of TLS 1.2 and TLS 1.3 cipher configuration. Previously, some deployments mixed TLS 1.3 cipher suites into the ciphers attribute. That is now a hard error: TLS 1.3 suites in ciphers are silently ignored and a warning is logged. Use the new dedicated cipherSuites attribute instead. To ease migration, Tomcat 9.0 will automatically move TLS 1.3 entries from ciphers to cipherSuites during parsing (this migration aid will be removed in Tomcat 12).

<!-- Before (incorrect, TLS 1.3 suites mixed in) -->
<SSLHostConfig ciphers="TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256" />

<!-- After (correct, separated) -->
<SSLHostConfig
    ciphers="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384"
    cipherSuites="TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384" />

Other notable TLS changes across the 9.0 branch:

• OCSP support added for JSSE-based TLS connectors, with configurable soft failure mode (disabled by default). Both JSSE and OpenSSL OCSP checks are now aligned in behaviour.
• A new strictSni attribute (default: true) rejects requests where the SNI hostname and HTTP Host header resolve to different SSLHostConfig instances. In practice, this is the correct and secure default, but it will reject requests from clients that send mismatched SNI/Host values -- review your reverse proxy and load balancer configurations.
• Deprecated cipher aliases SSLv3, EXPORT, EXPORT40, EXPORT56, KRB5, kFZA, aFZA, eFZA and FZA are no longer accepted in the ciphers attribute. Remove them from your SSL configurations.
• Memory leaks in the FFM OpenSSL code fixed: x509 objects, CA certificates, and certificate chains are now properly freed on error paths.
• TLS objects are dereferenced immediately on socket close, reducing memory pressure under high connection churn.

What HTTP/2 and connector improvements were made in Apache Tomcat 9.0?

HTTP/2 handling in 9.0 has received a steady stream of correctness and robustness fixes that matter most in high-throughput or proxy-fronted deployments.

A long-standing NIO+TLS bug was fixed where a response might not be fully written until the connection was closed, silently truncating content in non-blocking flush scenarios. This would manifest as intermittent partial responses under load, which is notoriously difficult to diagnose without packet captures. If you have seen unexplained response truncation with NIO+TLS, this fix (9.0.117) is the likely root cause.

• HTTP/2 HEADERS frame parsing bug fixed: an invalid frame no longer causes the connection to close without a GOAWAY frame, which was causing client-visible abrupt disconnects.
• HTTP/2 header validation relaxed: instead of a connection reset for invalid headers, Tomcat now returns a stream reset or a 400 response, which is both more correct and less disruptive to multiplexed connections.
• HTTP/2 request header read buffer is now properly reset (including size restoration) after a stream reset, preventing buffer bloat over long-lived connections.
• New drainTimeout attribute on the HTTP/2 UpgradeProtocol element lets you configure the interval between the two final GOAWAY frames during graceful shutdown, useful in load-balanced environments where you need downstream proxies to drain connections before the second GOAWAY.
• The noCompressionEncodings HTTP connector setting allows explicit exclusion of specific content encodings from compression, useful when upstream caches or clients cannot handle certain compressed encodings.
• Chunk extension validation added for chunked transfer encoding, closing a protocol-level attack surface.
• Trailer field filtering extended to HTTP trailers: control characters (excluding TAB) and high code points are replaced with a space, consistent with how regular header fields are handled.

In practice, teams running Tomcat behind an AWS ALB, nginx, or Apache httpd reverse proxy will benefit most from the HTTP/2 stream reset improvements -- these prevent a single misbehaving HTTP/2 client from taking down an entire multiplexed connection.

What authentication and session management fixes should Tomcat 9.0 operators know about?

Several authentication and session handling bugs were resolved across the 9.0 branch that can surface as hard-to-reproduce issues in SSO-heavy or load-balanced environments.

A race condition in SSO session tracking was fixed: when session IDs change after authentication (standard practice to prevent session fixation), the new ID was not being propagated to the SSO Valve, causing SSO entries to survive past their intended lifecycle and leak across users in some edge cases. This fix is in 9.0.111 and is a must-have for deployments using the SSO Valve.

• New ssoReauthenticationMode attribute on Authenticators allows per-Authenticator override of the SSO Valve's requireReauthentication setting. This is particularly relevant for SPNEGO -- delegated Kerberos credentials are now properly available to the web application when SSO reauthentication is enabled.
• CsrfPreventionFilter fixed to avoid adding duplicate CSRF tokens to URLs, which was causing token validation failures on redirects in some application frameworks.
• HttpSession.isNew() now correctly returns false once the client has joined the session, fixing a spec compliance issue that could cause application code checking this flag to misidentify returning clients as new ones.
• URL encoding errors in the Rewrite Valve now throw an exception rather than silently substituting a replacement character, making misconfigured rewrite rules fail fast instead of producing subtly wrong URLs.
• A new digestInRfc3112Order attribute on MessageDigestCredentialHandler was added to control salt+credential digest ordering. The current default (salt then credential) is non-RFC 3112 compliant; this will change in Tomcat 12. Existing deployments do not need to change anything now, but be aware this is a future migration item.

What deprecations and migration warnings should teams prepare for when running Apache Tomcat 9.0?

While Tomcat 9.0 remains under active support until March 2027, the branch is now signalling several configuration patterns that will not carry forward to Tomcat 10 and beyond -- some of which require immediate attention to avoid silent misbehaviour today.

The APR/Native Connector (the old JNI-based connector using APR) now logs an informational warning at startup recommending migration to the NIO Connector. Most teams already moved away from APR years ago, but if you are still running it for sendfile or native SSL performance reasons, the NIO2 connector with OpenSSL via FFM is the supported path going forward.

• RemoteAddrFilter / RemoteAddrValve deprecated -- Use RemoteCIDRFilter and RemoteCIDRValve instead. The CIDR variants support proper subnet notation and are the long-term replacement.
• APR Connector -- Still functional but now logs a deprecation notice. Plan migration to the NIO Connector.
• TLS 1.3 ciphers in ciphers attribute -- Silently ignored with a warning. Migrate to cipherSuites. The auto-migration shim in 9.0 will be removed in Tomcat 12.
• Single ciphers attribute for mixed TLS versions -- The migration aid (auto-moving TLS 1.3 suites to cipherSuites) is explicitly documented as a 9.0-only behaviour.
• Removed legacy SSL cipher aliases -- SSLv3, EXPORT*, KRB5, FZA family aliases are no longer accepted in SSLHostConfig ciphers. Audit your SSL configurations before upgrading from older 9.0 patch levels.
• digestInRfc3112Order -- The default salt+credential order in MessageDigestCredentialHandler will flip in Tomcat 12. Start planning if you use this handler for user credential storage.

This matters if you are planning a future migration to Tomcat 10 or 11: Tomcat 10 requires the switch from javax.* to jakarta.* namespaces in all application code. The Tomcat 9.0 deprecation signals are designed to reduce the delta when that migration comes.