Content

Table of Contents

Apache Tomcat 7.x vulnerabilities

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

released 2014-05-22 Fixed in Apache Tomcat 7.0.54

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 1588199, 1589997, 1590028 and 1590036.

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

Affects: 7.0.0-7.0.53

released 2014-03-30 Fixed in Apache Tomcat 7.0.53

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

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: 7.0.0-7.0.52

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 1578637 and 1578655.

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

Affects: 7.0.0-7.0.52

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

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: 7.0.0-7.0.52

released 17 Feb 2014 Fixed in Apache Tomcat 7.0.52

Note: The issue below was fixed in Apache Tomcat 7.0.51 but the release vote for the 7.0.51 release candidate did not pass. Therefore, although users must download 7.0.52 to obtain a version that includes a fix for this issue, version 7.0.51 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 7 uses a packaged renamed copy of Apache Commons FileUpload to implement the requirement of the Servlet 3.0 specification to support the processing of mime-multipart requests. Tomcat 7 was therefore affected by this issue.

This was fixed in revision 1565169.

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

Affects: 7.0.0-7.0.50

2014-01-08 Fixed in Apache Tomcat 7.0.50

Note: The issues below were fixed in Apache Tomcat 7.0.48 but the release votes for 7.0.48 to 7.0.49 did not pass. Therefore, although users must download 7.0.50 to obtain a version that includes fixes for these issues, versions 7.0.48 to 7.0.49 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 1521864 and 1549523.

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: 7.0.0 to 7.0.47

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

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

Affects: 7.0.0 to 7.0.47

2013-10-24 Fixed in Apache Tomcat 7.0.47

Note: The issue below was fixed in Apache Tomcat 7.0.43 but the release votes for 7.0.43 to 7.0.46 did not pass. Therefore, although users must download 7.0.47 to obtain a version that includes a fix for this issue, versions 7.0.43 to 7.0.46 are 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 1521854.

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

Affects: 7.0.0 to 7.0.42

released 9 May 2013 Fixed in Apache Tomcat 7.0.40

Moderate: Information disclosure CVE-2013-2071

Bug 54178 described a scenario where elements of a previous request may be exposed to a current request. This was very difficult to exploit deliberately but fairly likely to happen unexpectedly if an application used AsyncListeners that threw RuntimeExceptions.

This was fixed in revision 1471372.

The root cause of the problem was identified as a Tomcat bug on 2 April 2013. The Tomcat security team identified the security implications on 24 April 2013 and made those details public on 10 May 2013.

Affects: 7.0.0-7.0.39

released 21 Nov 2012 Fixed in Apache Tomcat 7.0.33

Important: Session fixation CVE-2013-2067

FORM authentication associates the most recent request requiring authentication with the current session. By repeatedly sending a request for an authenticated resource while the victim is completing the login form, an attacker could inject a request that would be executed using the victim's credentials.

This was fixed in revision 1408044.

This issue was identified by the Tomcat security team on 15 Oct 2012 and made public on 10 May 2013.

Affects: 7.0.0-7.0.32

released 9 Oct 2012 Fixed in Apache Tomcat 7.0.32

Important: Bypass of CSRF prevention filter CVE-2012-4431

The CSRF prevention filter could be bypassed if a request was made to a protected resource without a session identifier present in the request.

This was fixed in revision 1393088.

This issue was identified by the Tomcat security team on 8 September 2012 and made public on 4 December 2012.

Affects: 7.0.0-7.0.31

released 6 Sep 2012 Fixed in Apache Tomcat 7.0.30

Important: Denial of service CVE-2012-3544

When processing a request submitted using the chunked transfer encoding, Tomcat ignored but did not limit any extensions that were included. This allows a client to perform a limited DOS by streaming an unlimited amount of data to the server.

This was fixed in revisions 1378702 and 1378921.

This issue was reported to the Tomcat security team on 10 November 2011 and made public on 10 May 2013.

Affects: 7.0.0-7.0.29

Moderate: DIGEST authentication weakness CVE-2012-3439

Three weaknesses in Tomcat's implementation of DIGEST authentication were identified and resolved:

  1. Tomcat tracked client rather than server nonces and nonce count.
  2. When a session ID was present, authentication was bypassed.
  3. The user name and password were not checked before when indicating that a nonce was stale.

These issues reduced the security of DIGEST authentication making replay attacks possible in some circumstances.

This was fixed in revision 1377807.

The first issue was reported by Tilmann Kuhn to the Tomcat security team on 19 July 2012. The second and third issues were discovered by the Tomcat security team during the resulting code review. All three issues were made public on 5 November 2012.

Affects: 7.0.0-7.0.29

Important: Bypass of security constraints CVE-2012-3546

When using FORM authentication it was possible to bypass the security constraint checks in the FORM authenticator by appending /j_security_check to the end of the URL if some other component (such as the Single-Sign-On valve) had called request.setUserPrincipal() before the call to FormAuthenticator#authenticate().

This was fixed in revision 1377892.

This issue was identified by the Tomcat security team on 13 July 2012 and made public on 4 December 2012.

Affects: 7.0.0-7.0.29

released 19 Jun 2012 Fixed in Apache Tomcat 7.0.28

Important: Denial of service CVE-2012-2733

The checks that limited the permitted size of request headers were implemented too late in the request parsing process for the HTTP NIO connector. This enabled a malicious user to trigger an OutOfMemoryError by sending a single request with very large headers.

This was fixed in revision 1350301.

This was reported by Josh Spiewak to the Tomcat security team on 4 June 2012 and made public on 5 November 2012.

Affects: 7.0.0-7.0.27

Important: Denial of service CVE-2012-4534

When using the NIO connector with sendfile and HTTPS enabled, if a client breaks the connection while reading the response an infinite loop is entered leading to a denial of service. This was originally reported as bug 52858.

This was fixed in revision 1340218.

The security implications of this bug were reported to the Tomcat security team by Arun Neelicattu of the Red Hat Security Response Team on 3 October 2012 and made public on 4 December 2012.

Affects: 7.0.0-7.0.27

released 25 Nov 2011 Fixed in Apache Tomcat 7.0.23

Important: Denial of service CVE-2012-0022

Analysis of the recent hash collision vulnerability identified unrelated inefficiencies with Apache Tomcat's handling of large numbers of parameters and parameter values. These inefficiencies could allow an attacker, via a specially crafted request, to cause large amounts of CPU to be used which in turn could create a denial of service. The issue was addressed by modifying the Tomcat parameter handling code to efficiently process large numbers of parameters and parameter values.

This was fixed in revisions 1189899, 1190372, 1190482, 1194917, 1195225, 1195226, 1195537, 1195909, 1195944, 1195951, 1195977 and 1198641.

This was identified by the Tomcat security team on 21 October 2011 and made public on 17 January 2012.

Affects: 7.0.0-7.0.22

released 1 Oct 2011 Fixed in Apache Tomcat 7.0.22

Important: Information disclosure CVE-2011-3375

For performance reasons, information parsed from a request is often cached in two places: the internal request object and the internal processor object. These objects are not recycled at exactly the same time. When certain errors occur that needed to be added to the access log, the access logging process triggers the re-population of the request object after it has been recycled. However, the request object was not recycled before being used for the next request. That lead to information leakage (e.g. remote IP address, HTTP headers) from the previous request to the next request. The issue was resolved be ensuring that the request and response objects were recycled after being re-populated to generate the necessary access log entries.

This was fixed in revision 1176592.

This was identified by the Tomcat security team on 22 September 2011 and made public on 17 January 2012.

Affects: 7.0.0-7.0.21

Low: Privilege Escalation CVE-2011-3376

This issue only affects environments running web applications that are not trusted (e.g. shared hosting environments). The Servlets that implement the functionality of the Manager application that ships with Apache Tomcat should only be available to Contexts (web applications) that are marked as privileged. However, this check was not being made. This allowed an untrusted web application to use the functionality of the Manager application. This could be used to obtain information on running web applications as well as deploying additional web applications.

This was fixed in revision 1176588.

This was identified by Ate Douma on 27 September 2011 and made public on 8 November 2011.

Affects: 7.0.0-7.0.21

released 1 Sep 2011 Fixed in Apache Tomcat 7.0.21

Important: Authentication bypass and information disclosure CVE-2011-3190

Apache Tomcat supports the AJP protocol which is used with reverse proxies to pass requests and associated data about the request from the reverse proxy to Tomcat. The AJP protocol is designed so that when a request includes a request body, an unsolicited AJP message is sent to Tomcat that includes the first part (or possibly all) of the request body. In certain circumstances, Tomcat did not process this message as a request body but as a new request. This permitted an attacker to have full control over the AJP message permitting authentication bypass and information disclosure. This vulnerability only occurs when all of the following are true:

  • The org.apache.jk.server.JkCoyoteHandler AJP connector is not used
  • POST requests are accepted
  • The request body is not processed

This was fixed in revision 1162958.

This was reported publicly on 20th August 2011.

Affects: 7.0.0-7.0.20

Mitigation options:

  • Upgrade to Tomcat 7.0.21
  • Apply the appropriate patch
  • Configure both Tomcat and the reverse proxy to use a shared secret.
    (It is "requiredSecret" attribute in AJP <Connector>, "worker.workername.secret" directive for mod_jk. The mod_proxy_ajp module currently does not support shared secrets).

References:

released 11 Aug 2011 Fixed in Apache Tomcat 7.0.20

Important: Information disclosure CVE-2011-2729

Due to a bug in the capabilities code, jsvc (the service wrapper for Linux that is part of the Commons Daemon project) does not drop capabilities allowing the application to access files and directories owned by superuser. This vulnerability only occurs when all of the following are true:

  • Tomcat is running on a Linux operating system
  • jsvc was compiled with libcap
  • -user parameter is used

Affected Tomcat versions shipped with source files for jsvc that included this vulnerability.

This was fixed in revision 1153379.

This was identified by Wilfried Weissmann on 20 July 2011 and made public on 12 August 2011.

Affects: 7.0.0-7.0.19

released 19 Jul 2011 Fixed in Apache Tomcat 7.0.19

Low: Information disclosure CVE-2011-2526

Tomcat provides support for sendfile with the HTTP NIO and HTTP APR connectors. sendfile is used automatically for content served via the DefaultServlet and deployed web applications may use it directly via setting request attributes. These request attributes were not validated. When running under a security manager, this lack of validation allowed a malicious web application to do one or more of the following that would normally be prevented by a security manager:

  • return files to users that the security manager should make inaccessible
  • terminate (via a crash) the JVM

Additionally, these vulnerabilities only occur when all of the following are true:

  • untrusted web applications are being used
  • the SecurityManager is used to limit the untrusted web applications
  • the HTTP NIO or HTTP APR connector is used
  • sendfile is enabled for the connector (this is the default)

This was fixed in revisions 1145383, 1145489, 1145571, 1145694 and 1146005.

This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011.

Affects: 7.0.0-7.0.18

Note: The issues below were fixed in Apache Tomcat 7.0.17 but the release votes for the 7.0.17 and 7.0.18 release candidates did not pass. Therefore, although users must download 7.0.19 to obtain a version that includes a fix for these issues, versions 7.0.17 and 7.0.18 are not included in the list of affected versions.

Low: Information disclosure CVE-2011-2204

When using the MemoryUserDatabase (based on tomcat-users.xml) and creating users via JMX, an exception during the user creation process may trigger an error message in the JMX client that includes the user's password. This error message is also written to the Tomcat logs. User passwords are visible to administrators with JMX access and/or administrators with read access to the tomcat-users.xml file. Users that do not have these permissions but are able to read log files may be able to discover a user's password.

This was fixed in revision 1140070.

This was identified by Polina Genova on 14 June 2011 and made public on 27 June 2011.

Affects: 7.0.0-7.0.16

Low: Information disclosure CVE-2011-2481

The re-factoring of XML validation for Tomcat 7.0.x re-introduced the vulnerability previously reported as CVE-2009-0783. This was initially reported as a memory leak. If a web application is the first web application loaded, this bugs allows that web application to potentially view and/or alter the web.xml, context.xml and tld files of other web applications deployed on the Tomcat instance.

This was first fixed in revision 1137753, but reverted in revision 1138776 and finally fixed in revision 1138788.

This was identified by the Tomcat security team on 20 June 2011 and made public on 12 August 2011.

Affects: 7.0.0-7.0.16

released 12 May 2011 Fixed in Apache Tomcat 7.0.14

Important: Security constraint bypass CVE-2011-1582

An error in the fixes for CVE-2011-1088/CVE-2011-1183 meant that security constraints configured via annotations were ignored on the first request to a Servlet. Subsequent requests were secured correctly.

This was fixed in revision 1100832.

This was identified by the Tomcat security team on 13 April 2011 and made public on 17 May 2011.

Affects: 7.0.12-7.0.13

released 6 Apr 2011 Fixed in Apache Tomcat 7.0.12

Important: Information disclosure CVE-2011-1475

Changes introduced to the HTTP BIO connector to support Servlet 3.0 asynchronous requests did not fully account for HTTP pipelining. As a result, when using HTTP pipelining a range of unexpected behaviours occurred including the mixing up of responses between requests. While the mix-up in responses was only observed between requests from the same user, a mix-up of responses for requests from different users may also be possible.

This was fixed in revisions 1086349 and 1086352. (Note: HTTP pipelined requests are still likely to fail with the HTTP BIO connector but will do so in a secure manner.)

This was reported publicly on the Tomcat Bugzilla issue tracker on 22 Mar 2011.

Affects: 7.0.0-7.0.11

Moderate: Multiple weaknesses in HTTP DIGEST authentication CVE-2011-1184

Note: Mitre elected to break this issue down into multiple issues and have allocated the following additional references to parts of this issue: CVE-2011-5062, CVE-2011-5063 and CVE-2011-5064. The Apache Tomcat security team will continue to treat this as a single issue using the reference CVE-2011-1184.

The implementation of HTTP DIGEST authentication was discovered to have several weaknesses:

  • replay attacks were permitted
  • server nonces were not checked
  • client nonce counts were not checked
  • qop values were not checked
  • realm values were not checked
  • the server secret was hard-coded to a known string

The result of these weaknesses is that DIGEST authentication was only as secure as BASIC authentication.

This was fixed in revision 1087655.

This was identified by the Tomcat security team on 16 March 2011 and made public on 26 September 2011.

Affects: 7.0.0-7.0.11

Important: Security constraint bypass CVE-2011-1183

A regression in the fix for CVE-2011-1088 meant that security constraints were ignored when no login configuration was present in the web.xml and the web application was marked as meta-data complete.

This was fixed in revision 1087643.

This was identified by the Tomcat security team on 17 March 2011 and made public on 6 April 2011.

Affects: 7.0.11

released 11 Mar 2011 Fixed in Apache Tomcat 7.0.11

Important: Security constraint bypass CVE-2011-1088

When a web application was started, ServletSecurity annotations were ignored. This meant that some areas of the application may not have been protected as expected. This was partially fixed in Apache Tomcat 7.0.10 and fully fixed in 7.0.11.

This was fixed in revisions 1076586, 1076587, 1077995 and 1079752.

This was reported publicly on the Tomcat users mailing list on 2 Mar 2011.

Affects: 7.0.0-7.0.10

released 5 Feb 2011 Fixed in Apache Tomcat 7.0.8

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

Important: Remote Denial Of Service CVE-2011-0534

The NIO connector expands its buffer endlessly during request line processing. That behaviour can be used for a denial of service attack using a carefully crafted request.

This was fixed in revision 1065939.

This was identified by the Tomcat security team on 27 Jan 2011 and made public on 5 Feb 2011.

Affects: 7.0.0-7.0.6

released 14 Jan 2011 Fixed in Apache Tomcat 7.0.6

Low: Cross-site scripting CVE-2011-0013

The HTML Manager interface displayed web application provided data, such as display names, without filtering. A malicious web application could trigger script execution by an administrative user when viewing the manager pages.

This was fixed in revision 1057279.

This was identified by the Tomcat security team on 12 Nov 2010 and made public on 5 Feb 2011.

Affects: 7.0.0-7.0.5

released 1 Dec 2010 Fixed in Apache Tomcat 7.0.5

Low: Cross-site scripting CVE-2010-4172

The Manager application used the user provided parameters sort and orderBy directly without filtering thereby permitting cross-site scripting. The CSRF protection, which is enabled by default, prevents an attacker from exploiting this.

This was fixed in revision 1037778.

This was first reported to the Tomcat security team on 15 Nov 2010 and made public on 22 Nov 2010.

Affects: 7.0.0-7.0.4

released 21 Oct 2010 Fixed in Apache Tomcat 7.0.4

Low: SecurityManager file permission bypass CVE-2010-3718

When running under a SecurityManager, access to the file system is limited but web applications are granted read/write permissions to the work directory. This directory is used for a variety of temporary files such as the intermediate files generated when compiling JSPs to Servlets. The location of the work directory is specified by a ServletContect attribute that is meant to be read-only to web applications. However, due to a coding error, the read-only setting was not applied. Therefore, a malicious web application may modify the attribute before Tomcat applies the file permissions. This can be used to grant read/write permissions to any area on the file system which a malicious web application may then take advantage of. This vulnerability is only applicable when hosting web applications from untrusted sources such as shared hosting environments.

This was fixed in revision 1022134.

This was discovered by the Tomcat security team on 12 Oct 2010 and made public on 5 Feb 2011.

Affects: 7.0.0-7.0.3

released 11 Aug 2010 Fixed in Apache Tomcat 7.0.2

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

Important: Remote Denial Of Service and Information Disclosure Vulnerability CVE-2010-2227

Several flaws in the handling of the 'Transfer-Encoding' header were found that prevented the recycling of a buffer. A remote attacker could trigger this flaw which would cause subsequent requests to fail and/or information to leak between requests. This flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy should reject the invalid transfer encoding header.

This was fixed in revision 958911.

This was first reported to the Tomcat security team on 14 Jun 2010 and made public on 9 Jul 2010.

Affects: 7.0.0

Not a vulnerability in Tomcat

Low: Denial Of Service CVE-2012-5568

Sending an HTTP request 1 byte at a time will consume a thread from the connection pool until the request has been fully processed if using the BIO or APR/native HTTP connectors. Multiple requests may be used to consume all threads in the connection pool thereby creating a denial of service.

Since the relationship between the client side resources and server side resources is a linear one, this issue is not something that the Tomcat Security Team views as a vulnerability. This is a generic DoS problem and there is no magic solution. This issue has been discussed several times on the Tomcat mailing lists. The best place to start to review these discussions is the report for bug 54236.

This was first discussed on the public Tomcat users mailing list on 19 June 2009.

Affects: 7.0.0-7.0.x

Important: Remote Denial Of Service CVE-2010-4476

A JVM bug could cause Double conversion to hang JVM when accessing to a form based security constrained page or any page that calls javax.servlet.ServletRequest.getLocale() or javax.servlet.ServletRequest.getLocales(). A specially crafted request can be used to trigger a denial of service.

A work-around for this JVM bug was provided in revision 1066244.

This was first reported to the Tomcat security team on 01 Feb 2011 and made public on 31 Jan 2011.

Affects: 7.0.0-7.0.6

Moderate: TLS SSL Man In The Middle CVE-2009-3555

A vulnerability exists in the TLS protocol that allows an attacker to inject arbitrary requests into an TLS stream during renegotiation.

The TLS implementation used by Tomcat varies with connector. The blocking IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation provided by the JVM. The APR/native connector uses OpenSSL.

The BIO connector is vulnerable if the JSSE version used is vulnerable. To workaround a vulnerable version of JSSE, use the connector attribute allowUnsafeLegacyRenegotiation. It should be set to false (the default) to protect against this vulnerability.

The NIO connector prior to 7.0.10 is not vulnerable as it does not support renegotiation.

The NIO connector is vulnerable from version 7.0.10 onwards if the JSSE version used is vulnerable. To workaround a vulnerable version of JSSE, use the connector attribute allowUnsafeLegacyRenegotiation. It should be set to false (the default) to protect against this vulnerability.

The APR/native workarounds are detailed on the APR/native connector security page.

Users should be aware that the impact of disabling renegotiation will vary with both application and client. In some circumstances disabling renegotiation may result in some clients being unable to access the application.

This was worked-around in revision 891292.

Support for the new TLS renegotiation protocol (RFC 5746) that does not have this security issue:

  • For connectors using JSSE implementation provided by JVM: Added in Tomcat 7.0.8.
    Requires JRE that supports RFC 5746. For Oracle JRE that is known to be 6u22 or later.
  • For connectors using APR and OpenSSL:
    TBD. See APR/native connector security page.

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