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.

A malicious web application running on Apache Tomcat versions from 6.0.0 to 9.0.0.M9 was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.

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 ResourceLinkFactory implementation in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70, and 6.0.0 to 6.0.45 did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.

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.

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.

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.

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.

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.

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).

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.

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.

Apache Tomcat versions 9.0.28 to 9.0.30, 8.5.48 to 8.5.50, and 7.0.98 to 7.0.99 contain a regression that causes invalid Transfer-Encoding headers to be incorrectly processed, leading to a possibility of HTTP Request Smuggling if Tomcat is behind a reverse proxy that incorrectly handles the invalid Transfer-Encoding header in a particular manner.

In Apache Tomcat versions from 6.0.0 to 9.0.0.M9, a vulnerability allowed a malicious web application to bypass a configured SecurityManager via a Tomcat utility method accessible to web applications.

In Apache Tomcat versions 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, a regression in send file processing was introduced. If the send file processing completed quickly, it was possible for the same Processor to be added to the processor cache twice.

In Apache Tomcat versions from 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75, there was an issue with the use of the incorrect facade object in some calls to application listeners. This allowed untrusted applications to retain a reference to the request or response object, potentially accessing or modifying information associated with another web application.

Insufficient Session Expiration vulnerability in Apache Tomcat meant that if the session ID for an authenticated HTTP session was changed after a WebSocket connection had been established under that authenticated HTTP session, the WebSocket session would not be closed as required by the Jakarta WebSocket specification when the HTTP session ended.

Uncontrolled Resource Consumption vulnerability in Apache Tomcat via an allocation leak in the HTTP/2 backlog tracking when a stream is reset.

Improper Authentication vulnerability in Apache Tomcat meant that in some circumstances (e.g. CLIENT-CERT, SPNEGO) a user would be authenticated even if the user did not exist in the DataSourceRealm.

Improper Authorization vulnerability in Apache Tomcat caused by security-role-ref definitions being incorrectly used as role aliases within the Realm in addition to the correct usage with Request.isUserInRole().

Off-by-one Error vulnerability in Apache Tomcat impacting the [N] flag on the rewrite valves causes rewrite processing to restart at the second rule rather than the first rule.

Time-of-check Time-of-use (TOCTOU) race condition vulnerability in Apache Tomcat when creating unix domain sockets allows an unauthorized local user to access the socket. Affects versions from 11.0.0-M1 through 11.0.24, 10.1.0-M1 through 10.1.57, and 9.0.42 through 9.0.120.

In Apache Tomcat, the WebSocket chat example has an uncontrolled resource consumption vulnerability. Affected versions: 11.0.0-M20 through 11.0.24, 10.1.24 through 10.1.57, and 9.0.89 through 9.0.120.

A missing critical step in authentication was found in Apache Tomcat's JNDIRealm when configured to use GSSAPI. Attackers can authenticate without providing the correct password.