Apache Tomcat vulnerabilities

The vulnerability related to improper handling of case sensitivity in LockOutRealm in Apache Tomcat may lead to unauthorized access. It affects versions from 11.0.0-M1 to 11.0.21, from 10.1.0-M1 to 10.1.54, from 9.0.0.M1 to 9.0.117, from 8.5.0 to 8.5.100, and from 7.0.0 to 7.0.109.

A vulnerability in Apache Tomcat related to the exposure of the HTTP Authentication Header to unexpected hosts during WebSocket authentication. It affects versions from 11.0.0-M1 to 11.0.21, 10.1.0-M1 to 10.1.54, 9.0.2 to 9.0.117, 8.5.24 to 8.5.100, and 7.0.83 to 7.0.109.

There is a vulnerability in Apache Tomcat related to resource allocation without limits or throttling. This affects versions from 11.0.0-M1 to 11.0.21, from 10.1.0-M1 to 10.1.54, and from 9.0.0.M1 to 9.0.117.

A vulnerability in Apache Tomcat related to improper resource shutdown or release allows for a 'made you reset' attack. This affects versions from 11.0.0-M1 to 11.0.9, from 10.1.0-M1 to 10.1.43, and from 9.0.0.M1 to 9.0.107.

The HTTP/2 implementation in Apache Tomcat from version 9.0.0.M1 to 9.0.0.M21 and from 8.5.0 to 8.5.15 bypassed several security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using a specially crafted URL.

The HTTP/2 header parser in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M11 and 8.5.0 to 8.5.6 entered an infinite loop if a header larger than the available buffer was received. This made a denial of service attack possible.

The error page mechanism of the Java Servlet Specification requires that the original request and response be forwarded to the error page. For static files, the expected behavior is to serve the content of the file as if processing a GET request, which was not implemented in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43, and 7.0.0 to 7.0.77.

In Apache Tomcat versions 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, the handling of an HTTP/2 GOAWAY frame did not close streams associated with that connection waiting for a WINDOW_UPDATE, potentially leading to exhaustion of available processing threads.

A bug in the handling of pipelined requests in Apache Tomcat causes the request to be lost when send file processing of the previous request is completed. This can lead to responses being sent for the wrong requests.

The code in Apache Tomcat versions from 6.0.0 to 9.0.0.M11 allowed parsing of the HTTP request line with invalid characters. This could be exploited in conjunction with a proxy that also accepted these characters to inject data into the HTTP response.

A programming error was discovered in the processing of HTTPS requests in the Apache Tomcat servlet and JSP engine, which may result in denial of service due to an infinite loop. This issue arises from backporting the CVE-2016-6816 fix without including the fix for Tomcat bug 57544.

The session-persistence implementation in Apache Tomcat in versions 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 mishandles session attributes. This allows remote authenticated users to bypass intended SecurityManager restrictions and execute arbitrary code in a privileged context via a web application that places a crafted object in a session.

Apache Tomcat has a session fixation vulnerability affecting versions 7.x before 7.0.66, 8.x before 8.0.30, and 9.x before 9.0.0.M2. The issue arises when different session settings are used for deployments of multiple versions of the same web application, potentially allowing remote attackers to hijack user sessions.

Apache Tomcat versions 6.x before 6.0.44, 7.x before 7.0.55, and 8.x before 8.0.9 do not properly handle cases where an HTTP response occurs before finishing the reading of an entire request body. This allows remote attackers to cause a denial of service (thread consumption) via a series of aborted upload attempts.

Inconsistent interpretation of HTTP/2 requests ('HTTP Request/Response smuggling') vulnerability in Apache Tomcat caused by a regression in fix for CVE-2026-41293 can trigger request header mix-up. This issue affects Apache Tomcat: from 11.0.22 through 11.0.25, from 10.1.55 through 10.1.59, from 9.0.118 through 9.0.121. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue.

CLIENT_CERT authentication does not fail as expected for some scenarios when soft fail is disabled vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M14 through 11.0.25, from 10.1.22 through 10.1.59, from 9.0.92 through 9.0.121. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue.

A vulnerability in Apache Tomcat allows bypassing security constraints for any WebSocket endpoint via an alternate name. Affected versions include 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.59, and 9.0.0.M1 through 9.0.121. Users are advised to upgrade to 11.0.26, 10.1.60, or 9.0.122.

Incorrect Authorization vulnerability in Apache Tomcat's FORM authentication process allows the bypassing of a security constraint that limits user has access to a resource POST but not GET.

Authentication Bypass by Capture-replay vulnerability in Apache Tomcat's DIGEST authenticator. If, before windowSize requests have been made, a client makes a DIGEST authenticated request with a nonceCount on the upper boundary of the replay window then that request is replayable once only while the associated nonceCount remains within the replay window.

Improper input validation vulnerability in Apache Tomcat due to incomplete fix for CVE-2026-32990. Affects versions 11.0.20-11.0.24, 10.1.53-10.1.57, and 9.0.115-9.0.120.

Improper access control and incorrect authorization vulnerability in Apache Tomcat leads to security constraint bypass if a constraint for a longer path is specified before a more restrictive constraint for a shorter sub-path. Affects a wide range of versions from 7.0.0 through 11.0.24.

An insufficient technical documentation vulnerability in Apache Tomcat fails to clearly document the requirements for securely configuring the EncryptInterceptor. This affects multiple Tomcat versions from 7.0.100 through 11.0.23.

A vulnerability in Apache Tomcat's rewrite valve allows security constraint bypass due to improper handling of URL hex encoding. Affected versions include 11.0.0-M1 through 11.0.23, 10.1.0-M1 through 10.1.56, 9.0.0-M1 through 9.0.119, and 8.5.0 through 8.5.100.

An Always-Incorrect Control Flow Implementation vulnerability in Apache Tomcat causes special roles and empty authorization constraints to be omitted when the effective web.xml is logged. Affected versions include 11.0.0-M1 through 11.0.22, 10.1.0-M1 through 10.1.55, 9.0.0.M1 through 9.0.118, and 8.5.0 through 8.5.100.

A vulnerability was found in Apache Tomcat where a detection of error condition without action occurs when configuring CRLs for a FFM based connector. Affected versions are from 11.0.0-M1 through 11.0.22, from 10.1.0-M7 through 10.1.55, and from 9.0.83 through 9.0.118.

A vulnerability in the digest authentication mechanism in Apache Tomcat allows for authentication bypass. This affects versions from 11.0.0-M1 to 11.0.21, 10.1.0-M1 to 10.1.54, 9.0.0.M1 to 9.0.117, 8.5.0 to 8.5.100, and versions before 7.0.0.

The vulnerability related to improper input validation in Apache Tomcat may lead to unauthorized access or data manipulation. It affects versions from 11.0.0-M1 to 11.0.21, from 10.1.0-M1 to 10.1.54, from 9.0.0.M1 to 9.0.117, and from 10.0.0-M1 to 10.0.27.

Padding Oracle vulnerability in Apache Tomcat's EncryptInterceptor with default configuration. Allows an attacker to decrypt data transmitted over an encrypted channel.

Apache Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system that supported ANSI escape sequences, an attacker could use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker-controlled command.

Relative Path Traversal vulnerability in Apache Tomcat. The fix for bug 60013 introduced a regression where the rewritten URL was normalized before decoding, allowing an attacker to manipulate the request URI to bypass security constraints including /WEB-INF/ and /META-INF/ protection. If PUT requests are enabled, malicious files can be uploaded leading to remote code execution.

The 'Open Redirect' vulnerability in the FORM authentication feature of Apache Tomcat allows redirecting users to untrusted sites. This affects Apache Tomcat versions from 11.0.0-M1 to 11.0.0-M10, from 10.1.0-M1 to 10.0.12, from 9.0.0-M1 to 9.0.79, and from 8.5.0 to 8.5.92.

In Apache Tomcat 10.1.0-M1 to 10.1.0-M16, 10.0.0-M1 to 10.0.22, 9.0.30 to 9.0.64 and 8.5.50 to 8.5.81 the Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability.

If a web application sends a WebSocket message concurrently with the WebSocket connection closing when running on Apache Tomcat 8.5.0 to 8.5.75 or Apache Tomcat 9.0.0.M1 to 9.0.20, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors.

The documentation of Apache Tomcat versions 10.1.0-M1 to 10.1.0-M14, 10.0.0-M1 to 10.0.20, 9.0.13 to 9.0.62 and 8.5.38 to 8.5.78 for the EncryptInterceptor incorrectly stated it enabled Tomcat clustering to run over an untrusted network. This was not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly DoS risks.

Apache Tomcat 8.5.0 to 8.5.63, 9.0.0-M1 to 9.0.43 and 10.0.0-M1 to 10.0.2 did not properly validate incoming TLS packets. When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be used to trigger an infinite loop resulting in a denial of service.

Apache Tomcat versions 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46, and 8.5.0 to 8.5.66 incorrectly parsed the HTTP transfer-encoding request header in some circumstances, leading to request smuggling when used with a reverse proxy. Specifically, Tomcat ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response, honored the identity encoding, and did not ensure that chunked encoding was the final encoding.

A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker to authenticate using variations of a valid user name and/or to bypass some of the protection provided by the LockOut Realm. This issue affects Apache Tomcat 10.0.0-M1 to 10.0.5; 9.0.0.M1 to 9.0.45; 8.5.0 to 8.5.65.

The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue.

When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request.

Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59, and 7.0.0 to 7.0.106 are susceptible to JSP source code disclosure in some configurations when serving resources from a network location on the NTFS file system. The root cause is the unexpected behavior of the JRE API File.getCanonicalPath(), caused by inconsistent behavior of the Windows API (FindFirstFileW).

While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests.

If an HTTP/2 client connecting to Apache Tomcat exceeds the agreed maximum number of concurrent streams for a connection, a subsequent request may contain HTTP headers from a previous request instead of the intended ones. This could lead to users seeing responses for unexpected resources.

In Apache Tomcat versions 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104, the payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop, and multiple requests with invalid payload lengths could lead to a denial of service.

In Apache Tomcat versions 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56, an h2c direct connection did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service.

A specially crafted sequence of HTTP/2 requests sent to Apache Tomcat 10.0.0-M1 to 10.0.0-M5, 9.0.0.M1 to 9.0.35 and 8.5.0 to 8.5.55 could trigger high CPU usage for several seconds. If a sufficient number of such requests were made on concurrent HTTP/2 connections, the server could become unresponsive.

In Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103, if an attacker can control the contents and name of a file on the server, and the server is configured with PersistenceManager using FileStore and appropriate filters, remote code execution via deserialization is possible.

In Apache Tomcat 9.0.0.M1 to 9.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99 the HTTP header parsing code used an approach to end-of-line parsing that allowed some invalid HTTP headers to be parsed as valid. This led to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.