Apache Tomcat versions 7.0.0 to 7.0.84, 8.0.0.RC1 to 8.0.49 and 8.5.0 to 8.5.27 only apply security constraints defined by Servlets once those Servlets are loaded. Depending on the order that Servlets load, some security constraints may not be applied leading to unintended resource exposure.

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.85 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.50 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.28

Upstream Fixes:

Tomcat 7.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823322 http://svn.apache.org/viewvc?view=rev&rev=1824360

Tomcat 8.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823319 http://svn.apache.org/viewvc?view=rev&rev=1824359

Tomcat 8.5.x:

http://svn.apache.org/viewvc?view=rev&rev=1823314 http://svn.apache.org/viewvc?view=rev&rev=1824358

Apache Tomcat versions 7.0.0 to 7.0.84, 8.0.0.RC1 to 8.0.49 and 8.5.0 to 8.5.27 does not properly handle the URL empty string ("") when used as part of a security constraint definition. This can lead to the security constraint being ignored, leading to unitended exposure of resources.

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.85 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.50 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.28

Upstream Bug Report:

https://bz.apache.org/bugzilla/showbug.cgi?id=62067

Upstream Fixes:

Tomcat 7.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823309

Tomcat 8.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1814827

Tomcat 8.5.x:

http://svn.apache.org/viewvc?view=rev&rev=1823307

A flaw was found in Apache tomcat. 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.

References:

https://lists.apache.org/thread.html/23134c9b5a23892a205dc140cdd8c9c0add233600f76b313dda6bd75@%3Cannounce.tomcat.apache.org%3E

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.

Affected versions: 7.0.41 to 7.0.78, 8.0.0.RC1 to 8.0.44, 8.5.0 to 8.5.15

Upstream patches:

Tomcat 7: https://svn.apache.org/viewvc?view=revision&revision=1795816 Tomcat 8.0.x: https://svn.apache.org/viewvc?view=revision&revision=1795815 Tomcat 8.5.x: https://svn.apache.org/viewvc?view=revision&revision=1795814

External References:

https://tomcat.apache.org/security-7.html https://tomcat.apache.org/security-8.html

Last updated 18 August 2025

ResourceLinkFactory.setGlobalContext() is a public method and was accessible by web applications running under a security manager without any checks. 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.

External references:

http://seclists.org/bugtraq/2016/Feb/147

Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 does not place org.apache.catalina.manager.StatusManagerServlet on the org/apache/catalina/core/RestrictedServlets.properties list, which allows remote authenticated users to bypass intended SecurityManager restrictions and read arbitrary HTTP requests, and consequently discover session ID values, via a crafted web application.

Directory traversal vulnerability in RequestUtil.java in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.65, and 8.x before 8.0.27 allows remote authenticated users to bypass intended SecurityManager restrictions and list a parent directory via a /.. (slash dot dot) in a pathname used by a web application in a getResource, getResourceAsStream, or getResourcePaths call, as demonstrated by the $CATALINABASE/webapps directory.

The Mapper component in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.30, and 9.x before 9.0.0.M2 processes redirects before considering security constraints and Filters, which allows remote attackers to determine the existence of a directory via a URL that lacks a trailing / (slash) character.

It was found that the expression language resolver evaluated expressions within a privileged code section. A malicious web application could use this flaw to bypass security manager protections.

Upstream patches:

http://svn.apache.org/viewvc?view=revision&revision=1644019 http://svn.apache.org/viewvc?view=revision&revision=1645644

External References:

http://tomcat.apache.org/security-6.html#FixedinApacheTomcat6.0.44 http://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.59 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.17

java/org/apache/coyote/http11/filters/ChunkedInputFilter.java in Apache Tomcat 6.x before 6.0.42, 7.x before 7.0.55, and 8.x before 8.0.9 does not properly handle attempts to continue reading data after an error has occurred, which allows remote attackers to conduct HTTP request smuggling attacks or cause a denial of service (resource consumption) by streaming data with malformed chunked transfer coding.

Apache Tomcat before 6.0.40, 7.x before 7.0.54, and 8.x before 8.0.6 does not properly constrain the class loader that accesses the XML parser used with an XSLT stylesheet, which allows remote attackers to (1) read arbitrary files via a crafted web application that provides an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue, or (2) read files associated with different web applications on a single Tomcat instance via a crafted web application.

Integer overflow in java/org/apache/tomcat/util/buf/Ascii.java in Apache Tomcat before 6.0.40, 7.x before 7.0.53, and 8.x before 8.0.4, when operated behind a reverse proxy, allows remote attackers to conduct HTTP request smuggling attacks via a crafted Content-Length HTTP header.

It was found that the org.apache.catalina.servlets.DefaultServlet implementation in Apache Tomcat allowed the definition of XXEs in provided XSLTs. A malicious application could use this to circumvent security restrictions to disclose sensitive information.

Apache Tomcat did not limit the length of chunk sizes when using chunked transfer coding. A remote attacker could use this flaw to perform a denial of service attack against Tomcat, by streaming an unlimited quantity of data, leading to consumption of server resources.

Apache Tomcat before 6.0.39, 7.x before 7.0.50, and 8.x before 8.0.0-RC10 allows attackers to obtain "Tomcat internals" information by leveraging the presence of an untrusted web application with a context.xml, web.xml, .jspx, .tagx, or .tld XML document containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue.

Unrestricted file upload vulnerability in Apache Tomcat 7.x before 7.0.40, in certain situations involving outdated java.io.File code and a custom JMX configuration, allows remote attackers to execute arbitrary code by uploading and accessing a JSP file.

Apache Tomcat before 6.0.39, 7.x before 7.0.47, and 8.x before 8.0.0-RC3, when an HTTP connector or AJP connector is used, does not properly handle certain inconsistent HTTP request headers, which allows remote attackers to trigger incorrect identification of a request's length and conduct request-smuggling attacks via (1) multiple Content-Length headers or (2) a Content-Length header and a "Transfer-Encoding: chunked" header. NOTE: this vulnerability exists because of an incomplete fix for CVE-2005-2090.

Apache Tomcat before 6.0.39, 7.x before 7.0.50, and 8.x before 8.0.0-RC10 processes chunked transfer coding without properly handling (1) a large total amount of chunked data or (2) whitespace characters in an HTTP header value within a trailer field, which allows remote attackers to cause a denial of service by streaming data. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3544.

A session fixation flaw was found in the way FormAuthenticator module of Apache Tomcat, an Apache Servlet/JSP Engine, performed authentication requests management in certain circumstances (the most recent authentication request was associated with current user's session). An attacker could use this flaw to inject (and possibly successfully to complete) an authentication request, that would be executed using the credentials of the victim.

Relevant upstream patch: for Apache Tomcat 6.x: http://svn.apache.org/viewvc?view=revision&revision=1417891 for Apache Tomcat 7.x: http://svn.apache.org/viewvc?view=rev&rev=1408044

The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 caches information about the authenticated user within the session state, which makes it easier for remote attackers to bypass authentication via vectors related to the session ID.

The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 does not properly check for stale nonce values in conjunction with enforcement of proper credentials, which makes it easier for remote attackers to bypass intended access restrictions by sniffing the network for valid requests.

The replay-countermeasure functionality in the HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 tracks cnonce (aka client nonce) values instead of nonce (aka server nonce) and nc (aka nonce-count) values, which makes it easier for remote attackers to bypass intended access restrictions by sniffing the network for valid requests, a different vulnerability than CVE-2011-1184.

org/apache/catalina/filters/CsrfPreventionFilter.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.32 allows remote attackers to bypass the cross-site request forgery (CSRF) protection mechanism via a request that lacks a session identifier.

Apache Tomcat through 7.0.x allows remote attackers to cause a denial of service (daemon outage) via partial HTTP requests, as demonstrated by Slowloris.

In Apache Tomcat 10.1.0-M1 to 10.1.0-M16, 10.0.0-M1 to 10.0.22, 9.0.30 to 9.0.64 and 8.5.50 to 8.5.81 the Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability.

Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding.

A flaw was found in Apache Tomcat. If an HTTP/2 client exceeded the agreed maximum number of concurrent streams for a connection (in violation of the HTTP/2 protocol), it is possible that a subsequent request made on that connection could contain HTTP headers - including HTTP/2 pseudo headers - from a previous request rather than the intended headers. This could lead to users seeing responses for unexpected resources. The highest threat from this vulnerability is to data confidentiality.

Last updated 25 August 2025

A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker to authenticate using variations of a valid user name and/or to bypass some of the protection provided by the LockOut Realm. This issue affects Apache Tomcat 10.0.0-M1 to 10.0.5; 9.0.0.M1 to 9.0.45; 8.5.0 to 8.5.65.