Content

Table of Contents

Apache Tomcat 10.x vulnerabilities

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

14 September 2020 Fixed in Apache Tomcat 10.0.0-M8

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

5 July 2020 Fixed in Apache Tomcat 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

7 June 2020 Fixed in Apache Tomcat 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

11 May 2020 Fixed in Apache Tomcat 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