Content

Table of Contents

Apache Tomcat 9.x vulnerabilities

This page lists all security vulnerabilities fixed in released versions of Apache Tomcat 9.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 9.0 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.

5 January 2016 Fixed in Apache Tomcat 9.0.0.M3

Moderate: Security Manager bypass CVE-2016-0763

This issue only affects users running untrusted web applications under a security manager.

ResourceLinkFactory.setGlobalContext() is a public method and was accessible to web applications even when running under a security manager. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications.

This was fixed in revision 1725926.

This issue was identified by the Tomcat security team on 18 January 2016 and made public on 22 February 2016.

Affects: 9.0.0.M1 to 9.0.0.M2

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

Moderate: CSRF token leak CVE-2015-5351

The index page of the Manager and Host Manager applications included a valid CSRF token when issuing a redirect as a result of an unauthenticated request to the root of the web application. If an attacker had access to the Manager or Host Manager applications (typically these applications are only accessible to internal users, not exposed to the Internet), this token could then be used by the attacker to construct a CSRF attack.

This was fixed in revisions 1720652 and 1720655.

This issue was identified by the Tomcat security team on 8 December 2015 and made public on 22 February 2016.

Affects: 8.0.0.M1 to 9.0.0, 9.0.1.M1 to 9.0.1.M2-

Low: Security Manager bypass CVE-2016-0706

This issue only affects users running untrusted web applications under a security manager.

The internal StatusManagerServlet could be loaded by a malicious web application when a security manager was configured. This servlet could then provide the malicious web application with a list of all deployed applications and a list of the HTTP request lines for all requests currently being processed. This could have exposed sensitive information from other web applications, such as session IDs, to the web application.

This was fixed in revision 1722799.

This issue was identified by the Tomcat security team on 27 December 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1

Moderate: Security Manager bypass CVE-2016-0714

This issue only affects users running untrusted web applications under a security manager.

Tomcat provides several session persistence mechanisms. The StandardManager persists session over a restart. The PersistentManager is able to persist sessions to files, a database or a custom Store. The cluster implementation persists sessions to one or more additional nodes in the cluster. All of these mechanisms could be exploited to bypass a security manager. Session persistence is performed by Tomcat code with the permissions assigned to Tomcat internal code. By placing a carefully crafted object into a session, a malicious web application could trigger the execution of arbitrary code.

This was fixed in revisions 1725263 and 1725914.

This issue was identified by the Tomcat security team on 12 November 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1-9.0.0.M2