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 Tomcat 7.0.x has reached end of life and is no longer supported. Further vulnerabilities in the 7.0.x branch will not be fixed. Users should upgrade to 8.5.x or later to obtain security fixes.
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.
Low: Authentication weakness
Queries made by the JNDI Realm did not always correctly escape parameters. Parameter values could be sourced from user provided data (eg user names) as well as configuration data provided by an administrator. In limited circumstances it was possible for users to authenticate using variations of their user name and/or to bypass some of the protection provided by the LockOut Realm.
This was fixed with commit
This issue was reported publicly as
Affects: 7.0.0 to 7.0.108
Low: Fix for
The fix for
This was fixed with commit
This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 12 January 2021. The issue was made public on 1 March 2021.
Affects: 7.0.0 to 7.0.107
Important: Information disclosure
When serving resources from a network location using the NTFS file system
it was possible to bypass security constraints and/or view the source
code for JSPs in some configurations. The root cause was the unexpected
behaviour of the JRE API File.getCanonicalPath()
which in
turn was caused by the inconsistent behaviour of the Windows API
(FindFirstFileW
) in some circumstances.
This was fixed with commit
This issue was reported the Apache Tomcat Security team by Ilja Brander on 26 October 2020. The issue was made public on 14 January 2021.
Affects: 7.0.0 to 7.0.106
Important: WebSocket DoS
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 commits
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: 7.0.27 to 7.0.104
High: Remote Code Execution via session persistence
If:
PersistenceManager
with a FileStore
; andPersistenceManager
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;
andFileStore
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 7.0.104 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
This issue was reported to the Apache Tomcat Security Team by by jarvis threedr3am of pdd security research on 12 April 2020. The issue was made public on 20 May 2020.
Affects: 7.0.0 to 7.0.103
High: AJP Request Injection and potential Remote Code Execution
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. Prior to Tomcat 7.0.100, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required.
Prior to this vulnerability report, the known risks of an attacker being able to access the AJP port directly were:
This vulnerability report identified a mechanism that allowed the following:
Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible.
It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31 or later. Users should note that a number of changes were made to the default AJP Connector configuration in 7.0.100 to harden the default configuration. It is likely that users upgrading to 7.0.100 or later will need to make small changes to their configurations as a result.
This was fixed with commits
This issue was reported to the Apache Tomcat Security Team on 3 January 2020. The issue was made public on 24 February 2020.
Affects: 7.0.0 to 7.0.99
Low: HTTP Request Smuggling
The HTTP header parsing code used an approach to end-of-line (EOL) parsing that allowed some invalid HTTP headers to be parsed as valid. This led to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.
This was fixed with commit
This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 25 December 2019. The issue was made public on 24 February 2020.
Affects: 7.0.0 to 7.0.99
Low: HTTP Request Smuggling
The refactoring in 7.0.98 introduced a regression. The result of the regression was that invalid Transfer-Encoding headers were incorrectly processed leading to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.
This was fixed with commit
This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 12 December 2019. The issue was made public on 24 February 2020.
Affects: 7.0.98 to 7.0.99
Low: Session fixation
When using FORM authentication there was a narrow window where an attacker could perform a session fixation attack. The window was considered too narrow for an exploit to be practical but, erring on the side of caution, this issue has been treated as a security vulnerability.
This was fixed with commit
This issue was reported to the Apache Tomcat Security Team by William Marlow (IBM) on 19 November 2019. The issue was made public on 18 December 2019.
Affects: 7.0.0 to 7.0.98
Note: The issue below was fixed in Apache Tomcat 7.0.98 but the release vote for the 7.0.98 release candidate did not pass. Therefore, although users must download 7.0.99 to obtain a version that includes the fix for this issue, version78.0.98 is not included in the list of affected versions.
Moderate: Local Privilege Escalation
When Tomcat is configured with the JMX Remote Lifecycle Listener, a local attacker without access to the Tomcat process or configuration files is able to manipulate the RMI registry to perform a man-in-the-middle attack to capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and gain complete control over the Tomcat instance.
The JMX Remote Lifecycle Listener will be deprecated in future Tomcat releases, will be removed for Tomcat 10 and may be removed from all Tomcat releases some time after 31 December 2020.
Users should also be aware of
This was fixed with commit
This issue was reported to the Apache Tomcat Security Team by An Trinh of Viettel Cyber Security on 10 October 2019. The issue was made public on 18 December 2019.
Affects: 7.0.0 to 7.0.97
Important: Remote Code Execution on Windows
When running on Windows with enableCmdLineArguments enabled, the CGI Servlet is vulnerable to Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows. The CGI Servlet is disabled by default. For a detailed explanation of the JRE behaviour, see Markus Wulftange's blog and this archived MSDN blog.
This was fixed with commit
This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program sponsored by the EU FOSSA-2 project on 3rd March 2019. The issue was made public on 10 April 2019.
Affects: 7.0.0 to 7.0.93
Low: XSS in SSI printenv
The SSI printenv command echoes user provided data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website.
This was fixed with commit
This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program sponsored by the EU FOSSA-2 project on 7th March 2019. The issue was made public on 17 May 2019.
Affects: 7.0.0 to 7.0.93
Moderate: Open Redirect
When the default servlet returned a redirect to a directory (e.g.
redirecting to /foo/
when the user requested
/foo
) a specially crafted URL could be used to cause the
redirect to be generated to any URI of the attackers choice.
This was fixed in revision
This issue was reported to the Apache Tomcat Security Team by Sergey Bobrov on 28 August 2018 and made public on 3 October 2018.
Affects: 7.0.23 to 7.0.90
Low: host name verification missing in WebSocket client
The host name verification when using TLS with the WebSocket client was missing. It is now enabled by default.
This was fixed in revision
This issue was reported publicly on 11 June 2018 and formally announced as a vulnerability on 22 July 2018.
Affects: 7.0.25 to 7.0.88
Low: CORS filter has insecure defaults
The defaults settings for the CORS filter are insecure and enable
supportsCredentials
for all origins. It is expected that
users of the CORS filter will have configured it appropriately for their
environment rather than using it in the default configuration. Therefore,
it is expected that most users will not be impacted by this issue.
This was fixed in revision
This issue was reported publicly on 1 May 2018 and formally announced as a vulnerability on 16 May 2018.
Important: A bug in the UTF-8 decoder can lead to DoS
An improper handing of overflow in the UTF-8 decoder with supplementary characters can lead to an infinite loop in the decoder causing a Denial of Service.
This was fixed in revision
This issue was reported publicly on 6 April 2018 and formally announced as a vulnerability on 22 July 2018.
Affects: 7.0.28 to 7.0.88
Important: Security constraint annotations applied too
late
Security constraints defined by annotations of Servlets were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them.
This was fixed in revisions
This issue was identified by the Apache Tomcat Security on 1 February 2018 and made public on 23 February 2018.
Affects: 7.0.0 to 7.0.84
Important: Security constraints mapped to context root are
ignored
The URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected.
This was fixed in revision
This issue was reported publicly as
Affects: 7.0.0 to 7.0.84
Low: Incorrectly documented CGI search algorithm
Note: The issue below was fixed in Apache Tomcat 7.0.83 but the release vote for the 7.0.83 release candidate did not pass. Therefore, although users must download 7.0.84 to obtain a version that includes the fix for this issue, version 7.0.83 is not included in the list of affected versions.
As part of the fix for bug
This was fixed in revision
This issue was reported to the Apache Tomcat Security Team by Jan Michael Greiner on 17 September 2017 and made public on 31 January 2018.
Affects: 7.0.79 to 7.0.82
Important: Remote Code Execution
When running with HTTP PUTs enabled (e.g. via setting the
readonly
initialisation parameter of the Default servlet to
false) it was possible to upload a JSP file to the server via a specially
crafted request. This JSP could then be requested and any code it
contained would be executed by the server.
This was fixed in revisions
This issue was first reported publicly followed by multiple reports to the Apache Tomcat Security Team on 20 September 2017.
Affects: 7.0.0 to 7.0.81
Important: Information Disclosure
When using a VirtualDirContext it was possible to bypass security constraints and/or view the source code of JSPs for resources served by the VirtualDirContext using a specially crafted request.
This was fixed in revision
This issue was identified by the Tomcat Security Team on 10 August 2017 and made public on 19 September 2017.
Affects: 7.0.0 to 7.0.80
Important: Remote Code Execution
Note: The issue below was fixed in Apache Tomcat 7.0.80 but the release vote for the 7.0.81 release candidate did not pass. Therefore, although users must download 7.0.81 to obtain a version that includes the fix for this issue, version 7.0.80 is not included in the list of affected versions.
When running on Windows with HTTP PUTs enabled (e.g. via setting the
readonly
initialisation parameter of the Default to false)
it was possible to upload a JSP file to the server via a specially
crafted request. This JSP could then be requested and any code it
contained would be executed by the server.
This was fixed in revisions
This issue was reported responsibly to the Apache Tomcat Security Team by iswin from 360-sg-lab (360观星实验室) on 26 July 2017 and made public on 19 September 2017.
Affects: 7.0.0 to 7.0.79
Moderate: Cache Poisoning
The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.
This was fixed in revision
The issue was reported as bug
Affects: 7.0.41 to 7.0.78
Important: Security Constraint Bypass
The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method.
If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. Tomcat's Default Servlet did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page.
Notes for other user provided error pages:
This was fixed in revisions
This issue was reported responsibly to the Apache Tomcat Security Team by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai, India as a vulnerability that allowed the restrictions on OPTIONS and TRACE requests to be bypassed on 21 April 2017. The full implications of this issue were identified by the Tomcat Security Team on 24 April 2017. This issue was made public on 6 June 2017.
Affects: 7.0.0 to 7.0.77
Important: Information Disclosure
A bug in the handling of the pipelined requests when send file was used resulted in the pipelined request being lost when send file processing of the previous request completed. This could result in responses appearing to be sent for the wrong request. For example, a user agent that sent requests A, B and C could see the correct response for request A, the response for request C for request B and no response for request C.
This was fixed in revision
This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.
Affects: 7.0.0 to 7.0.76
Low: Information Disclosure
While investigating bug 60718, it was noticed that some calls to application listeners did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.
This was fixed in revision
This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.
Affects: 7.0.0 to 7.0.75
Important: Information Disclosure
Note: The issue below was fixed in Apache Tomcat 7.0.74 but the release vote for the 7.0.74 release candidate did not pass. Therefore, although users must download 7.0.75 to obtain a version that includes the fix for this issue, version 7.0.74 is not included in the list of affected versions.
A bug in the error handling of the send file code for the NIO HTTP connector resulted in the current Processor object being added to the Processor cache multiple times. This in turn meant that the same Processor could be used for concurrent requests. Sharing a Processor can result in information leakage between requests including, but not limited to, session ID and the response body.
This was fixed in revision
This issue was identified as affecting 7.0.x by the Apache Tomcat Security Team on 3 January 2016 and made public on 5 January 2017.
Affects: 7.0.0 to 7.0.73
Important: Remote Code Execution
The JmxRemoteLifecycleListener
was not updated to take
account of Oracle's fix for
This was fixed in revision
This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.
Affects: 7.0.0 to 7.0.72
Important: Information Disclosure
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
This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.
Affects: 7.0.0 to 7.0.72
Note: The issues below were fixed in Apache Tomcat 7.0.71 but the release vote for the 7.0.71 release candidate did not pass. Therefore, although users must download 7.0.72 to obtain a version that includes fixes for these issues, version 7.0.71 is not included in the list of affected versions.
Low: Unrestricted Access to Global Resources
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
This issue was identified by the Apache Tomcat Security Team on 18 January 2016 and made public on 27 October 2016.
Affects: 7.0.0 to 7.0.70
Low: Security Manager Bypass
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
This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.
Affects: 7.0.0 to 7.0.70
Low: System Property Disclosure
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
This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.
Affects: 7.0.0 to 7.0.70
Low: Security Manager Bypass
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
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: 7.0.0 to 7.0.70
Low: Timing Attack
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
This issue was identified by the Apache Tomcat Security Team on 1 January 2016 and made public on 27 October 2016.
Affects: 7.0.0 to 7.0.70
Moderate: Denial of Service
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
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: 7.0.0 to 7.0.69
Low: Directory disclosure
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 associated with being able to
determine if a web application was deployed at a given path.
This was fixed in revisions
This issue was identified by Mark Koek of QCSec on 12 October 2015 and made public on 22 February 2016.
Affects: 7.0.0 to 7.0.67
Moderate: CSRF token leak
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
This issue was identified by the Tomcat security team on 8 December 2015 and made public on 22 February 2016.
Affects: 7.0.1 to 7.0.67
Low: Security Manager bypass
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
This issue was identified by the Tomcat security team on 27 December 2015 and made public on 22 February 2016.
Affects: 7.0.0 to 7.0.67
Moderate: Security Manager bypass
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
This issue was identified by the Tomcat security team on 12 November 2015 and made public on 22 February 2016.
Affects: 7.0.0 to 7.0.67
Moderate: Security Manager bypass
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
This issue was identified by the Tomcat security team on 18 January 2016 and made public on 22 February 2016.
Affects: 7.0.0 to 7.0.67
Note: The issue below was fixed in Apache Tomcat 7.0.66 but the release vote for the 7.0.66 release candidate did not pass. Therefore, although users must download 7.0.67 to obtain a version that includes a fix for this issue, version 7.0.66 is not included in the list of affected versions.
Low: Session Fixation
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 revision
This issue was identified by the Tomcat security team on 22 June 2014 and made public on 22 February 2016.
Affects: 7.0.5 to 7.0.65
Low: Limited directory traversal
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
This issue was identified by the Tomcat security team on 12 August 2015 and made public on 22 February 2016.
Affects: 7.0.0 to 7.0.64
Note: The issue below was fixed in Apache Tomcat 7.0.58 but the release vote for the 7.0.58 release candidate did not pass. Therefore, although users must download 7.0.59 to obtain a version that includes a fix for this issue, versions 7.0.58 is not included in the list of affected versions.
Moderate: Security Manager bypass
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
This issue was identified by the Tomcat security team on 2 November 2014 and made public on 14 May 2015.
Affects: 7.0.0 to 7.0.57
Important: Request Smuggling
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 revision
This issue was identified by the Tomcat security team on 30 May 2014 and made public on 9 February 2015.
Affects: 7.0.0 to 7.0.54
Low: Denial of Service
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
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: 7.0.0 to 7.0.54
Low: Information Disclosure
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
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
Important: Denial of Service
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
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
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
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
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
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
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
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
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
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
The fix for CVE-2012-3544 was not complete. It did not cover the following cases:
This was fixed in revisions
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
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
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
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
The fix for CVE-2005-2090 was not complete. It did not cover the following cases:
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
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
Moderate: Information disclosure
Bug
This was fixed in revision
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
Important: Remote Code Execution
In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important.
For this attack to succeed all of the following requirements must be met:
Note that requirements 2 and 3 may be replaced with the following requirement:
In this case (requirements 1, 4, 5, 6 and 7 met) a similar vulnerability may exist on any Servlet container, not just Apache Tomcat.
This was fixed in revision
This issue was identified by Pierre Ernst of the VMware Security Engineering, Communications and Response group (vSECR) and reported to the Tomcat security team via the Pivotal security team on 5 September 2014. It was made public on 10 September 2014.
Affects: 7.0.0 to 7.0.39
Important: Session fixation
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
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
Important: Bypass of CSRF prevention filter
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
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
Important: Denial of service
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
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
Three weaknesses in Tomcat's implementation of DIGEST authentication were identified and resolved:
These issues reduced the security of DIGEST authentication making replay attacks possible in some circumstances.
This was fixed in revision
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
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
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
Important: Denial of service
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
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
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
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
Important: Denial of service
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
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
Important: Information disclosure
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
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
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
This was identified by Ate Douma on 27 September 2011 and made public on 8 November 2011.
Affects: 7.0.0-7.0.21
Important: Authentication bypass and information disclosure
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:
This was fixed in
This was reported publicly on 20th August 2011.
Affects: 7.0.0-7.0.20
Mitigation options:
requiredSecret
" attribute in AJP <Connector>,
"worker.workername.secret
" directive for mod_jk.
The mod_proxy_ajp module currently does not support shared secrets).References:
Important: Information disclosure
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:
Affected Tomcat versions shipped with source files for jsvc that included this vulnerability.
This was fixed in
This was identified by Wilfried Weissmann on 20 July 2011 and made public on 12 August 2011.
Affects: 7.0.0-7.0.19
Low: Information disclosure
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:
Additionally, these vulnerabilities only occur when all of the following are true:
This was fixed in revisions
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
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
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
The re-factoring of XML validation for Tomcat 7.0.x re-introduced the
vulnerability previously reported as
This was first fixed in
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
Important: Security constraint bypass
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
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
Important: Information disclosure
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
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:
The result of these weaknesses is that DIGEST authentication was only as secure as BASIC authentication.
This was fixed in
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
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
This was identified by the Tomcat security team on 17 March 2011 and made public on 6 April 2011.
Affects: 7.0.11
Important: Security constraint bypass
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
This was reported publicly on the Tomcat users mailing list on 2 Mar 2011.
Affects: 7.0.0-7.0.10
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
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
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
Low: Cross-site scripting
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
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
Low: Cross-site scripting
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
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
Low: SecurityManager file permission bypass
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
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
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
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
This was first reported to the Tomcat security team on 14 Jun 2010 and made public on 9 Jul 2010.
Affects: 7.0.0
Important: Denial of Service
In February 2015 a single user reported high CPU usage (
It was (and still is) believed that an application bug was the most
likely root cause. Therefore,
In November 2016,
Tomcat releases from the Apache Software Foundation were not affected as
the ASF did not release any versions that contained the fix for
This issue was first announced on 13 February 2017.
Affects: Debian, Ubuntu and potentially other downstream distributions.
Low: Denial Of Service
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
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
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
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
Support for the new TLS renegotiation protocol (RFC 5746) that does not have this security issue:
Important: Remote Memory Read
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.
This issue was first announced on 7 April 2014.
Affects: OpenSSL 1.0.1-1.0.1f, tcnative 1.1.24-1.1.29