Content

Table of Contents

Apache Tomcat 8.x vulnerabilities

This page lists all security vulnerabilities fixed in released versions of Apache Tomcat 8.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 8.0 those are building.html and BUILDING.txt. Both files can be found in the webapps/docs subdirectory of a binary distributive. 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.

13 June 2016 Fixed in Apache Tomcat 8.5.3 and 8.0.36

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 1743722 for 8.5.x and revision 1743738 for 8.0.x.

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: 8.5.0 to 8.5.2, 8.0.0.RC1 to 8.0.35

8 February 2016 Fixed in Apache Tomcat 8.0.32

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

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 1713185 and 1723506.

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

Affects: 8.0.0.RC1 to 8.0.30

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 1720658 and 1720660.

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

Affects: 8.0.0.RC1 to 8.0.30

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

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

Affects: 8.0.0.RC1 to 8.0.30

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 1726196 and 1726203.

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

Affects: 8.0.0.RC1 to 8.0.30

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

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

Affects: 8.0.0.RC1 to 8.0.30

6 December 2015 Fixed in Apache Tomcat 8.0.30

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 1715207 and 1717209.

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

Affects: 8.0.0.RC1 to 8.0.29

1 October 2015 Fixed in Apache Tomcat 8.0.27

Low: Limited directory traversal CVE-2015-5174

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

When accessing resources via the ServletContext methods getResource() getResourceAsStream() and getResourcePaths() the paths should be limited to the current web application. The validation was not correct and paths of the form "/.." were not rejected. Note that paths starting with "/../" were correctly rejected. This bug allowed malicious web applications running under a security manager to obtain a directory listing for the directory in which the web application had been deployed. This should not be possible when running under a security manager. Typically, the directory listing that would be exposed would be for $CATALINA_BASE/webapps.

This was fixed in revisions 1696281 and 1700897.

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

Affects: 8.0.0-RC1 to 8.0.26

16 January 2015 Fixed in Apache Tomcat 8.0.17

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

Moderate: Security Manager bypass CVE-2014-7810

Malicious web applications could use expression language to bypass the protections of a Security Manager as expressions were evaluated within a privileged code section.

This was fixed in revisions 1644018 and 1645642.

This issue was identified by the Tomcat security team on 2 November 2014 and made public on 14 May 2015.

Affects: 8.0.0-RC1 to 8.0.15

24 June 2014 Fixed in Apache Tomcat 8.0.9

Important: Request Smuggling CVE-2014-0227

It was possible to craft a malformed chunk as part of a chunked request that caused Tomcat to read part of the request body as a new request.

This was fixed in revisions 1600984, 1601329, 1601330 and 1601332.

This issue was identified by the Tomcat security team on 30 May 2014 and made public on 9 February 2015.

Affects: 8.0.0-RC1 to 8.0.8

Low: Denial of Service CVE-2014-0230

When a response for a request with a request body is returned to the user agent before the request body is fully read, by default Tomcat swallows the remaining request body so that the next request on the connection may be processed. There was no limit to the size of request body that Tomcat would swallow. This permitted a limited Denial of Service as Tomcat would never close the connection and a processing thread would remain allocated to the connection.

This was fixed in revision 1603770 and improved in revisions 1603775, 1603779, 1609175 and 1659294.

This issue was disclosed to the Tomcat security team by AntBean@secdig from the Baidu Security Team on 4 June 2014 and made public on 9 April 2015.

Affects: 8.0.0-RC1 to 8.0.8

beta, 21 May 2014 Fixed in Apache Tomcat 8.0.8

Note: The issue below was fixed in Apache Tomcat 8.0.6 but the release votes for the 8.0.6 and 8.0.7 release candidates did not pass. Therefore, although users must download 8.0.8 to obtain a version that includes a fix for this issue, versions 8.0.6 and 8.0.7 are not included in the list of affected versions.

Low: Information Disclosure CVE-2014-0119

In limited circumstances it was possible for a malicious web application to replace the XML parsers used by Tomcat to process XSLTs for the default servlet, JSP documents, tag library descriptors (TLDs) and tag plugin configuration files. The injected XML parser(s) could then bypass the limits imposed on XML external entities and/or have visibility of the XML files processed for other web applications deployed on the same Tomcat instance.

This was fixed in revisions 1588193, 1589837, 1589980, 1589983, 1589985, 1589990 and 1589992.

This issue was identified by the Tomcat security team on 12 April 2014 and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.5

beta, 27 Mar 2014 Fixed in Apache Tomcat 8.0.5

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

Important: Denial of Service CVE-2014-0075

It was possible to craft a malformed chunk size as part of a chucked request that enabled an unlimited amount of data to be streamed to the server, bypassing the various size limits enforced on a request. This enabled a denial of service attack.

This was fixed in revision 1578337.

This issue was reported to the Tomcat security team by David Jorm of the Red Hat Security Response Team on 28 February 2014 and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.3

Important: Denial of Service CVE-2014-0095

A regression was introduced in 1519838 that caused AJP requests to hang if an explicit content length of zero was set on the request. The hanging request consumed a request processing thread which could lead to a denial of service.

This was fixed in revision 1578392.

This issue was reported as a possible bug via the Tomcat users mailing list on 3 March 2014 and the security implications were identified by the Tomcat security team on the same day. This issue was made public on 27 May 2014.

Affects: 8.0.0-RC2 to 8.0.3

Important: Information disclosure CVE-2014-0096

The default servlet allows web applications to define (at multiple levels) an XSLT to be used to format a directory listing. When running under a security manager, the processing of these was not subject to the same constraints as the web application. This enabled a malicious web application to bypass the file access constraints imposed by the security manager via the use of external XML entities.

This was fixed in revisions 1578610 and 1578611.

This issue was identified by the Tomcat security team on 27 February 2014 and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.3

Important: Information disclosure CVE-2014-0099

The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header.

This was fixed in revision 1578812.

A test case that demonstrated the parsing bug was sent to the Tomcat security team on 13 March 2014 but no context was provided. The security implications were identified by the Tomcat security team the day the report was received and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.3

beta, 11 Feb 2014 Fixed in Apache Tomcat 8.0.3

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

Important: Denial of Service CVE-2014-0050

It was possible to craft a malformed Content-Type header for a multipart request that caused Apache Tomcat to enter an infinite loop. A malicious user could, therefore, craft a malformed request that triggered a denial of service.

The root cause of this error was a bug in Apache Commons FileUpload. Tomcat 8 uses a packaged renamed copy of Apache Commons FileUpload to implement the requirement of the Servlet 3.0 and later specifications to support the processing of mime-multipart requests. Tomcat 8 was therefore affected by this issue.

This was fixed in revision 1565163.

This issue was reported to the Apache Software Foundation on 04 Feb 2014 and accidently made public on 06 Feb 2014.

Affects: 8.0.0-RC1 to 8.0.1

alpha, 26 Dec 2013 Fixed in Apache Tomcat 8.0.0-RC10

Note: The issue below was fixed in Apache Tomcat 8.0.0-RC6 but the release votes for 8.0.0-RC6 to 8.0.0-RC9 did not pass. Therefore, although users must download 8.0.0-RC10 to obtain a version that includes a fix for this issue, versions 8.0.0-RC6 to 8.0.0-RC9 are not included in the list of affected versions.

Important: Denial of service CVE-2013-4322

The fix for CVE-2012-3544 was not complete. It did not cover the following cases:

  • chunk extensions were not limited
  • whitespace after the : in a trailing header was not limited

This was fixed in revisions 1521834 and 1549522.

The first part of this issue was identified by the Apache Tomcat security team on 27 August 2013 and the second part by Saran Neti of TELUS Security Labs on 5 November 2013. It was made public on 25 February 2014.

Affects: 8.0.0-RC1 to 8.0.0-RC5

Low: Information disclosure CVE-2013-4590

Application provided XML files such as web.xml, context.xml, *.tld, *.tagx and *.jspx allowed XXE which could be used to expose Tomcat internals to an attacker. This vulnerability only occurs when Tomcat is running web applications from untrusted sources such as in a shared hosting environment.

This was fixed in revision 1549528.

This issue was identified by the Apache Tomcat security team on 29 October 2013 and made public on 25 February 2014.

Affects: 8.0.0-RC1 to 8.0.0-RC5

alpha, 23 Sep 2013 Fixed in Apache Tomcat 8.0.0-RC3

Note: The issue below was fixed in Apache Tomcat 8.0.0-RC2 but the release vote for 8.0.0-RC2 did not pass. Therefore, although users must download 8.0.0-RC3 to obtain a version that includes a fix for this issue, version 8.0.0-RC2 is not included in the list of affected versions.

Important: Information disclosure CVE-2013-4286

The fix for CVE-2005-2090 was not complete. It did not cover the following cases:

  • content-length header with chunked encoding over any HTTP connector
  • multiple content-length headers over any AJP connector

Requests with multiple content-length headers or with a content-length header when chunked encoding is being used should be rejected as invalid. When multiple components (firewalls, caches, proxies and Tomcat) process a sequence of requests where one or more requests contain either multiple content-length headers or a content-length header when chunked encoding is being used and several components do not reject the request and make different decisions as to which content-length header to use an attacker can poison a web-cache, perform an XSS attack and obtain sensitive information from requests other then their own. Tomcat now rejects requests with multiple content-length headers or with a content-length header when chunked encoding is being used.

This was fixed in revision 1521829.

This issue was identified by the Apache Tomcat security team on 15 August 2013 and made public on 25 February 2014.

Affects: 8.0.0-RC1

Not a vulnerability in Tomcat

Important: Remote Memory Read CVE-2014-0160 (a.k.a. "Heartbleed")

A bug in certain versions of OpenSSL can allow an unauthenticated remote user to read certain contents of the server's memory. Binary versions of tcnative 1.1.24 - 1.1.29 include this vulnerable version of OpenSSL. tcnative 1.1.30 and later ship with patched versions of OpenSSL.

An explanation of how to deterine whether you are vulnerable and what steps to take, see the Tomcat Wiki's Heartbleed page.

This issue was first announced on 7 April 2014.

Affects: OpenSSL 1.0.1-1.0.1f, tcnative 1.1.24-1.1.29