Last updated 25 August 2025
Last updated 18 August 2025
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 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
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
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.
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 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.
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.
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.
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 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.
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 cross-site-scripting flaw was discovered in the manager application. It reflected the user provided parameters sort and orderBy directly without filtering applied.
The issue affects Tomcat 6 (impact=moderate):
From 6.0.12 to 6.0.29 and was fixed in r1037779:
http://svn.apache.org/viewvc?rev=1037779&view=rev
Upstream 6.0.30 will correct this flaw as noted:
http://tomcat.apache.org/security-6.html
The issue affects Tomcat 7 (impact=low, as caught by CSRF protection) : From 7.0.0 to 7.0.4 and was fixed in r1037778:
http://svn.apache.org/viewvc?rev=1037778&view=rev
Upstream 7.0.5 will correct this flaw as noted:
http://tomcat.apache.org/security-7.html
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.
java/org/apache/coyote/http11/InternalNioInputBuffer.java in the HTTP NIO connector in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.28 does not properly restrict the request-header size, which allows remote attackers to cause a denial of service (memory consumption) via a large amount of header data.
Apache Tomcat 5.5.x before 5.5.35, 6.x before 6.0.34, and 7.x before 7.0.23 uses an inefficient approach for handling parameters, which allows remote attackers to cause a denial of service (CPU consumption) via a request that contains many parameters and parameter values, a different vulnerability than CVE-2011-4858.