Apache Tomcat^®

This page lists all security vulnerabilities fixed in released versions of Apache Tomcat 10.x. Each vulnerability is given a security impact rating by the Apache Tomcat security team — please note that this rating may vary from platform to platform. We also list the versions of Apache Tomcat the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Note: Vulnerabilities that are not Tomcat vulnerabilities but have either been incorrectly reported against Tomcat or where Tomcat provides a workaround are listed at the end of this page.

Please note that binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Apache Tomcat version that you are using. For Tomcat 10.0.x those are building.html and BUILDING.txt. Both files can be found in the webapps/docs subdirectory of a binary distribution. You may also want to review the Security Considerations page in the documentation.

If you need help on building or configuring Tomcat or other help on following the instructions to mitigate the known vulnerabilities listed here, please send your questions to the public Tomcat Users mailing list

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Tomcat Security Team. Thank you.

• Fixed in Apache Tomcat 10.0.23
• Fixed in Apache Tomcat 10.1.0-M17
• Fixed in Apache Tomcat 10.0.21
• Fixed in Apache Tomcat 10.1.0-M15
• Fixed in Apache Tomcat 10.0.20
• Fixed in Apache Tomcat 10.1.0-M14
• Fixed in Apache Tomcat 10.0.16
• Fixed in Apache Tomcat 10.1.0-M10
• Fixed in Apache Tomcat 10.0.12
• Fixed in Apache Tomcat 10.1.0-M6
• Fixed in Apache Tomcat 10.0.7
• Fixed in Apache Tomcat 10.0.6
• Fixed in Apache Tomcat 10.0.5
• Fixed in Apache Tomcat 10.0.4
• Fixed in Apache Tomcat 10.0.2
• Fixed in Apache Tomcat 10.0.0-M10
• Fixed in Apache Tomcat 10.0.0-M8
• Fixed in Apache Tomcat 10.0.0-M7
• Fixed in Apache Tomcat 10.0.0-M6
• Fixed in Apache Tomcat 10.0.0-M5
• Not a vulnerability in Tomcat

Low: Apache Tomcat XSS in examples web application CVE-2022-34305

The Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability.

This was fixed with commit 1a7e95d9.

This issue was reported to the Apache Tomcat Security team on 22 June 2022. The issue was made public on 23 June 2022.

Affects: 10.0.0-M1 to 10.0.22

Low: Apache Tomcat XSS in examples web application CVE-2022-34305

The Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability.

This was fixed with commit d6251d1c.

This issue was reported to the Apache Tomcat Security team on 22 June 2022. The issue was made public on 23 June 2022.

Affects: 10.1.0-M1 to 10.1.0-M16

Low: Apache Tomcat EncryptInterceptor DoS CVE-2022-29885

The documentation 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.

This was fixed with commit 36826ea6.

This issue was reported to the Apache Tomcat Security team by 4ra1n on 17 April 2022. The issue was made public on 10 May 2022.

Affects: 10.0.0-M1 to 10.0.20

Low: Apache Tomcat EncryptInterceptor DoS CVE-2022-29885

The documentation 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.

This was fixed with commit 0fa7721f.

This issue was reported to the Apache Tomcat Security team by 4ra1n on 17 April 2022. The issue was made public on 10 May 2022.

Affects: 10.1.0-M1 to 10.1.0-M14

Note: The issue below was fixed in Apache Tomcat 10.0.19 but the release vote for the 10.0.19 release candidate did not pass. Therefore, although users must download 10.0.20 to obtain a version that includes a fix for these issues, version 10.0.19 is not included in the list of affected versions.

High: Information Disclosure CVE-2021-43980

The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.

This was fixed with commit 17f177ee.

This issue was reported to the Apache Tomcat Security team by Adam Thomas, Richard Hernandez and Ryan Schmitt on 11 November 2021. The issue was made public on 28 September 2022.

Affects: 10.0.0-M1 to 10.0.18

Note: The issue below was fixed in Apache Tomcat 10.1.0-M13 but the release vote for the 10.1.0-M13 release candidate did not pass. Therefore, although users must download 10.1.0-M14 to obtain a version that includes a fix for these issues, version 10.1.0-M13 is not included in the list of affected versions.

High: Information Disclosure CVE-2021-43980

The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.

This was fixed with commit 9651b83a.

This issue was reported to the Apache Tomcat Security team by Adam Thomas, Richard Hernandez and Ryan Schmitt on 11 November 2021. The issue was made public on 28 September 2022.

Affects: 10.1.0-M1 to 10.1.0-M12

Note: The issue below was fixed in Apache Tomcat 10.0.15 but the release vote for the 10.0.15 release candidate did not pass. Therefore, although users must download 10.0.16 to obtain a version that includes a fix for these issues, version 10.0.15 is not included in the list of affected versions.

Low: Local Privilege Escalation CVE-2022-23181

The fix for bug CVE-2020-9484 introduced a time of check, time of use vulnerability that allowed a local attacker to perform actions with the privileges of the user that the Tomcat process is using. This issue is only exploitable when Tomcat is configured to persist sessions using the FileStore.

This was fixed with commit 094800b1.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 10 December 2021. The issue was made public on 26 January 2022.

Affects: 10.0.0-M5 to 10.0.14

Note: The issue below was fixed in Apache Tomcat 10.1.0-M9 but the release vote for the 10.1.0-M9 release candidate did not pass. Therefore, although users must download 10.1.0-M10 to obtain a version that includes a fix for these issues, version 10.1.0-M9 is not included in the list of affected versions.

Low: Local Privilege Escalation CVE-2022-23181

The fix for bug CVE-2020-9484 introduced a time of check, time of use vulnerability that allowed a local attacker to perform actions with the privileges of the user that the Tomcat process is using. This issue is only exploitable when Tomcat is configured to persist sessions using the FileStore.

This was fixed with commit 70da1aaa.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 10 December 2021. The issue was made public on 26 January 2022.

Affects: 10.1.0-M1 to 10.1.0-M8

Important: Denial of Service CVE-2021-42340

The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.

This was fixed with commit 31d62426.

The memory leak was reported publicly via the users mailing list on 23 September 2021. The security implications were identified by the Tomcat Security team the same day. The issue was made public on 14 October 2021.

Affects: 10.0.0-M10 to 10.0.11

Important: Denial of Service CVE-2021-42340

The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.

This was fixed with commit d5a6660c.

The memory leak was reported publicly via the users mailing list on 23 September 2021. The security implications were identified by the Tomcat Security team the same day. The issue was made public on 14 October 2021.

Affects: 10.1.0-M1 to 10.1.0-M5

Important: Request Smuggling CVE-2021-33037

Apache Tomcat did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility of request smuggling when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the transfer-encoding header if the client declared it would only accept an HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not ensure that, if present, the chunked encoding was the final encoding.

This was fixed with commits eee0d024, 506134f9 and 19d11556.

This issue was reported to the Apache Tomcat Security team by Bahruz Jabiyev, Steven Sprecher and Kaan Onarlioglu of NEU seclab on 7 May 2021. The issue was made public on 12 July 2021.

Affects: 10.0.0-M1 to 10.0.6

Low: Authentication weakness CVE-2021-30640

Queries made by the JNDI Realm did not always correctly escape parameters. Parameter values could be sourced from user provided data (eg user names) as well as configuration data provided by an administrator. In limited circumstances it was possible for users to authenticate using variations of their user name and/or to bypass some of the protection provided by the LockOut Realm.

This was fixed with commits f4d9bdef, 4e61e1d6, d5303a50, b930d0b3, 17208c64, bd4d1fbe, 81f16b0a and eeb73512.

This issue was reported publicly as 65224.

Affects: 10.0.0-M1 to 10.0.5

Important: Denial of Service CVE-2021-30639

An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS.

Applications that do not use non-blocking I/O are not exposed to this vulnerability.

This was fixed with commit b59099e4.

This issue was reported publicly as 65203.

Affects: 10.0.3 to 10.0.4

Note: The issue below was fixed in Apache Tomcat 10.0.3 but the release vote for the 10.0.3 release candidate did not pass. Therefore, although users must download 10.0.4 to obtain a version that includes a fix for these issues, version 10.0.3 is not included in the list of affected versions.

Important: Denial of Service CVE-2021-41079

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.

This was fixed with commit 34115fb3.

This issue was first reported to the Apache Tomcat Security Team by Thomas Wozenilek on 26 February 2021 but could not be confirmed. A speculative fix was applied on 3 March 2021. On 14 September 2021 David Frankson of Infinite Campus independently reported the issue and included a test case. This allowed both the issue and the speculative fix to be verified. The issue was made public on 15 September 2021.

Affects: 10.0.0-M1 to 10.0.2

Note: The issues below were fixed in Apache Tomcat 10.0.1 but the release vote for the 10.0.1 release candidate did not pass. Therefore, although users must download 10.0.2 to obtain a version that includes a fix for these issues, version 10.0.1 is not included in the list of affected versions.

Low: Fix for CVE-2020-9484 was incomplete CVE-2021-25329

The fix for CVE-2020-9484 was incomplete. When using a highly unlikely configuration edge case, the Tomcat instance was still vulnerable to CVE-2020-9484. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published non-upgrade mitigations for CVE-2020-9484 also apply to this issue.

This was fixed with commit 6d66e99e.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 12 January 2021. The issue was made public on 1 March 2021.

Affects: 10.0.0-M1 to 10.0.0

Important: Request mix-up with h2c CVE-2021-25122

When responding to new h2c connection requests, Apache Tomcat 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.

This was fixed with commit dd757c0a.

This issue was identified by the Apache Tomcat Security team on 11 January 2021. The issue was made public on 1 March 2021.

Affects: 10.0.0-M1 to 10.0.0

Important: Information disclosure CVE-2021-24122

When serving resources from a network location using the NTFS file system it was possible to bypass security constraints and/or view the source code for JSPs in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances.

This was fixed with commit 7f004ac4.

This issue was reported the Apache Tomcat Security team by Ilja Brander on 26 October 2020. The issue was made public on 14 January 2021.

Affects: 10.0.0-M1 to 10.0.0-M9

Moderate: HTTP/2 request header mix-up CVE-2020-17527

While investigating issue 64830 it was discovered that Apache Tomcat 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.

This was fixed with commit 8d2fe689.

This issue was identified by the Apache Tomcat Security team on 10 November 2020. The issue was made public on 3 December 2020.

Affects: 10.0.0-M1 to 10.0.0-M9

Moderate: HTTP/2 request mix-up CVE-2020-13943

If an HTTP/2 client exceeded the agreed maximum number of concurrent streams for a connection (in violation of the HTTP/2 protocol), it was possible that a subsequent request made on that connection could contain HTTP headers - including HTTP/2 pseudo headers - from a previous request rather than the intended headers. This could lead to users seeing responses for unexpected resources.

This was fixed with commit 1bbc650c.

This issue was identified by the Apache Tomcat Security team on 23 July 2020. The issue was made public on 12 October 2020.

Affects: 10.0.0-M1 to 10.0.0-M7

Important: WebSocket DoS CVE-2020-13935

The payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.

This was fixed with commit 1c1c77b0.

This issue was reported publicly via the Apache Bugzilla instance on 28 June 2020 and included references to high CPU but no specific reference to denial of service. The associated DoS risks were identified by the Apache Tomcat Security Team the same day. The issue was made public on 14 July 2020.

Affects: 10.0.0-M1 to 10.0.0-M6

Moderate: HTTP/2 DoS CVE-2020-13934

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.

This was fixed with commit c9167ae3.

This issue was reported publicly via the Apache Tomcat Users mailing list on 22 June 2020 without reference to the potential for DoS. After further discussion to identify the steps necessary to reproduce the issue, the root cause of the issue and the associated DoS risks were identified by the Apache Tomcat Security Team on 26 June 2020. The issue was made public on 14 July 2020.

Affects: 10.0.0-M1 to 10.0.0-M6

Important: HTTP/2 DoS CVE-2020-11996

A specially crafted sequence of HTTP/2 requests 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.

This was fixed with commit 9434a44d.

This issue was reported publicly via the Apache Tomcat Users mailing list on 21 May 2020 without reference to the potential for DoS. The DoS risks were identified by the Apache Tomcat Security Team the same day. The issue was made public on 25 June 2020.

Affects: 10.0.0-M1 to 10.0.0-M5

Important: Remote Code Execution via session persistence CVE-2020-9484

If:

• an attacker is able to control the contents and name of a file on the server; and
• the server is configured to use the PersistenceManager with a FileStore; and
• the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and
• the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over;

then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control.

Note: All of conditions above must be true for the attack to succeed.

As an alternative to upgrading to 10.0.0-M5 or later, users may configure the PersistenceManager with an appropriate value for sessionAttributeValueClassNameFilter to ensure that only application provided attributes are serialized and deserialized.

This was fixed with commit bb33048e.

This issue was reported to the Apache Tomcat Security Team by jarvis threedr3am of pdd security research on 12 April 2020. The issue was made public on 20 May 2020.

Affects: 10.0.0-M1 to 10.0.0-M4

Critical: Remote Code Execution via log4j CVE-2021-44228

Apache Tomcat 10.x has no dependency on any version of log4j.

Web applications deployed on Apache Tomcat may have a dependency on log4j. You should seek support from the application vendor in this instance.

It is possible to configure Apache Tomcat 10.x to use log4j 2.x for Tomcat's internal logging. This requires explicit configuration and the addition of the log4j 2.x library. Anyone who has switched Tomcat's internal logging to log4j 2.x is likely to need to address this vulnerability.

In most cases, disabling the problematic feature will be the simplest solution. Exactly how to do that depends on the exact version of log4j 2.x being used. Details are provided on the log4j 2.x security page.