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.

8 November 2016 Fixed in Apache Tomcat 9.0.0.M13

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

Important: Remote Code Execution CVE-2016-8735

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be accessible to an attacker even when the listener is used.

This was fixed in revision 1767644.

This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.

Affects: 9.0.0.M1 to 9.0.0.M11

Important: Denial of Service CVE-2016-6817

The HTTP/2 header parser entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.

This was fixed in revision 1765794.

This issue was reported as 60232 on 10 October 2016 and the security implications identified by the Apache Tomcat Security Team on the same day. It was made public on 22 November 2016.

Affects: 9.0.0.M1 to 9.0.0.M11

Important: Information Disclosure CVE-2016-6816

The code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack and/or obtain sensitive information from requests other then their own.

This was fixed in revision 1767641.

This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.

Affects: 9.0.0.M1 to 9.0.0.M11

5 September 2016 Fixed in Apache Tomcat 9.0.0.M10

Low: Unrestricted Access to Global Resources CVE-2016-6797

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

This was fixed in revision 1757271.

This issue was identified by the Apache Tomcat Security Team on 18 January 2016 and made public on 27 October 2016.

Affects: 9.0.0.M1 to 9.0.0.M9

Low: Security Manager Bypass CVE-2016-6796

A malicious web application was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.

This was fixed in revisions 1758487 and 1763232.

This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.

Affects: 9.0.0.M1 to 9.0.0.M9

Low: System Property Disclosure CVE-2016-6794

When a SecurityManager is configured, a web application's ability to read system properties should be controlled by the SecurityManager. Tomcat's system property replacement feature for configuration files could be used by a malicious web application to bypass the SecurityManager and read system properties that should not be visible.

This was fixed in revision 1754445.

This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.

Affects: 9.0.0.M1 to 9.0.0.M9

Low: Security Manager Bypass CVE-2016-5018

A malicious web application was able to bypass a configured SecurityManager via a Tomcat utility method that was accessible to web applications.

This was fixed in revisions 1754714 and 1760300.

This issue was discovered by Alvaro Munoz and Alexander Mirosh of the HP Enterprise Security Team and reported to the Apache Tomcat Security Team on 5 July 2016. It was made public on 27 October 2016.

Affects: 9.0.0.M1 to 9.0.0.M9

Low: Timing Attack CVE-2016-0762

The Realm implementations did not process the supplied password if the supplied user name did not exist. This made a timing attack possible to determine valid user names. Note that the default configuration includes the LockOutRealm which makes exploitation of this vulnerability harder.

This was fixed in revision 1758499.

This issue was identified by the Apache Tomcat Security Team on 1 January 2016 and made public on 27 October 2016.

Affects: 9.0.0.M1 to 9.0.0.M9

13 June 2016 Fixed in Apache Tomcat 9.0.0.M8

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

Moderate: Denial of Service CVE-2016-3092

Apache Tomcat uses a package renamed copy of Apache Commons FileUpload to implement the file upload requirements of the Servlet specification. A denial of service vulnerability was identified in Commons FileUpload that occurred when the length of the multipart boundary was just below the size of the buffer (4096 bytes) used to read the uploaded file. This caused the file upload process to take several orders of magnitude longer than if the boundary was the typical tens of bytes long.

This was fixed in revision 1743700.

This issue was identified by the TERASOLUNA Framework Development Team and reported to the Apache Commons team via JPCERT on 9 May 2016. It was made public on 21 June 2016.

Affects: 9.0.0.M1 to 9.0.0.M6

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.

Low: Directory disclosure CVE-2015-5345

When accessing a directory protected by a security constraint with a URL that did not end in a slash, Tomcat would redirect to the URL with the trailing slash thereby confirming the presence of the directory before processing the security constraint. It was therefore possible for a user to determine if a directory existed or not, even if the user was not permitted to view the directory. The issue also occurred at the root of a web application in which case the presence of the web application was confirmed, even if a user did not have access.

The solution was to implement the redirect in the DefaultServlet so that any security constraints and/or security enforcing Filters were processed before the redirect. The Tomcat team recognised that moving the redirect could cause regressions so two new Context configuration options (mapperContextRootRedirectEnabled and mapperDirectoryRedirectEnabled) were introduced. The initial default was false for both since this was more secure. However, due to regressions such as Bug 58765 the default for mapperContextRootRedirectEnabled was later changed to true since it was viewed that the regression was more serious than the security risk of associated with being able to determine if a web application was deployed at a given path.

This was fixed in revisions 1715206, 1716882 and 1716894.

This issue was identified by Mark Koek of QCSec on 12 October 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1

Low: Session Fixation CVE-2015-5346

When recycling the Request object to use for a new request, the requestedSessionSSL field was not recycled. This meant that a session ID provided in the next request to be processed using the recycled Request object could be used when it should not have been. This gave the client the ability to control the session ID. In theory, this could have been used as part of a session fixation attack but it would have been hard to achieve as the attacker would not have been able to force the victim to use the 'correct' Request object. It was also necessary for at least one web application to be configured to use the SSL session ID as the HTTP session ID. This is not a common configuration.

This was fixed in revisions 1713184 and 1723414.

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

Affects: 9.0.0.M1

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: 9.0.0.M1

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