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.
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
Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.
Older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.
Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in the number guess example for Apache Tomcat.
Apache Tomcat is vulnerable to cross-site scripting, caused by improper validation of user-supplied input by the SSI printenv command. A remote attacker could exploit this vulnerability to execute script in a victim's Web browser within the security context of the hosting Web site, once the URL is clicked. An attacker could use this vulnerability to steal the victim's cookie-based authentication credentials.
If the ROOT (default) web application is configured to use FORM authentication then it is possible that a specially crafted URL could be used to trigger a redirect to an URL of the attackers choice.
https://lists.apache.org/thread/71wvwprtx2j2m54fovq9zr7gbm2wow2f https://github.com/advisories/GHSA-q3mw-pvr8-9ggc
Last updated 25 August 2025
A flaw was found in the RMI registry implementation in the RMI component of OpenJDK. Incorrect handling of the server-side dispatch could lead to selection of an incorrect skeleton class.
A flaw was found in Apache Tomcat. When serving resources from a network location using the NTFS file system, it was possible to bypass security constraints and view the source code for JSPs in some configurations. The root cause was the unexpected behavior of the JRE API File.getCanonicalPath(), which was caused by the inconsistent behavior of the Windows API (FindFirstFileW) in some circumstances. The highest threat from this vulnerability is to confidentiality.
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
If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109.
The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue.
Last updated 18 August 2025
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.
Incomplete Cleanup vulnerability in Apache Tomcat.
When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next.
Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue.
Improper Input Validation vulnerability in Apache Tomcat.
Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.81 and from 8.5.0 through 8.5.93 did not correctly parse HTTP trailer headers. A specially crafted, invalid trailer header could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.
Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fix the issue.
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. 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 the 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. The highest threat with this vulnerability is system availability.
Apache Tomcat information disclosure CVE-2023-28708
When using the RemoteIpFilter with requests received from a reverse proxy via HTTP that include the X-Forwarded-Proto header set to https, session cookies created by Tomcat did not include the secure attribute. This could result in the user agent transmitting the session cookie over an insecure channel.
Affects: 8.5.0 to 8.5.85
https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.86 https://bz.apache.org/bugzilla/showbug.cgi?id=66471 https://github.com/apache/tomcat/commit/5b72c94e8b2c4ada63a1d91dc527bf4d8fd1f510
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
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