Apache Tomcat contains an unspecified vulnerability that allows for remote code execution if JmxRemoteLifecycleListener is used and an attacker can reach Java Management Extension (JMX) ports. This CVE exists because this listener wasn't updated for consistency with the Oracle patched issues for CVE-2016-3427 which affected credential types.
Last updated 25 August 2025
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
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 HTT 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.
Affects: 7.0.0 to 7.0.77, 8.0.0.RC1 to 8.0.43, 8.5.0 to 8.5.14
Upstream fixes:
Tomcat 7.x:
https://svn.apache.org/viewvc?view=revision&revision=1793471 https://svn.apache.org/viewvc?view=revision&revision=1793491
Tomcat 8.0.x:
https://svn.apache.org/viewvc?view=revision&revision=1793470 https://svn.apache.org/viewvc?view=revision&revision=1793489
Tomcat 8.5.x:
https://svn.apache.org/viewvc?view=revision&revision=1793469 https://svn.apache.org/viewvc?view=revision&revision=1793488
External References:
https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.78 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.44 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.15
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.
Affected versions: 7.0.0 to 7.0.75, 8.0.0.RC1 to 8.0.41, 8.5.0 to 8.5.11
Upstream fixes:
Tomcat 7.x:
https://svn.apache.org/viewvc?view=revision&revision=1785777
Tomcat 8.0.x:
https://svn.apache.org/viewvc?view=revision&revision=1785776
Tomcat 8.5.x:
https://svn.apache.org/viewvc?view=revision&revision=1785775
References:
https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.76 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.42 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.12
A bug in the error handling of the send file code for the NIO HTTP connector in Apache Tomcat 9.0.0.M1 to 9.0.0.M13, 8.5.0 to 8.5.8, 8.0.0.RC1 to 8.0.39, 7.0.0 to 7.0.73 and 6.0.16 to 6.0.48 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, not not limited to, session ID and the response body. The bug was first noticed in 8.5.x onwards where it appears the refactoring of the Connector code for 8.5.x onwards made it more likely that the bug was observed. Initially it was thought that the 8.5.x refactoring introduced the bug but further investigation has shown that the bug is present in all currently supported Tomcat versions.
It was discovered that 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, or obtain sensitive information from requests other then their own.
In Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8. ...
Last updated 25 August 2025
Last updated 18 August 2025
A malicious web application running on Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.
Last updated 18 August 2025
A bug in the handling of the pipelined requests in Apache Tomcat 9.0.0.M1 to 9.0.0.M18, 8.5.0 to 8.5.12, 8.0.0.RC1 to 8.0.42, 7.0.0 to 7.0.76, and 6.0.0 to 6.0.52, when send file was used, results 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.
Apache Tomcat is vulnerable to a denial of service, caused by HTTP/2 connection window exhaustion on write. By failing to send WINDOWUPDATE messages, a remote attacker could exploit this vulnerability to block threads on the server and cause a denial of service.
A flaw was discovered in Apache Tomcat, where a Java Runtime Environment can pass a command-line argument in the Windows operating system. The execution of arbitrary commands via Tomcat’s Common Gateway Interface (CGI) Servlet, allows an attacker to perform remote code execution.
Flaw affecting tomcat 8.0.0.RC1 to 8.0.52 and 9.0.0.M1 to 9.0.9 . The host name verification when using TLS with the WebSocket client was not enabled by default.
Upstream patch:
http://svn.apache.org/viewvc?view=revision&revision=1833757 http://svn.apache.org/viewvc?view=rev&rev=1833759
References:
https://tomcat.apache.org/security-8.html https://tomcat.apache.org/security-9.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
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
In Apache Tomcat 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, the refactoring of the HTTP connectors introduced a regression in the send file processing. If the send file processing completed quickly, it was possible for the Processor to be added to the processor cache twice. This could result in the same Processor being used for multiple requests which in turn could lead to unexpected errors and/or response mix-up.
In Apache Tomcat 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, the handling of an HTTP/2 GOAWAY frame for a connection did not close streams associated with that connection that were currently waiting for a WINDOWUPDATE before allowing the application to write more data. These waiting streams each consumed a thread. A malicious client could therefore construct a series of HTTP/2 requests that would consume all available processing threads.
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.
A flaw was found in Apache Tomcat, where the HTTP/2 implementation accepted streams with excessive numbers of SETTINGS frames and also permitted clients to keep streams open, which enables them to cause server-side threads to block. This flaw eventually leads to a denial of service attack.
The HTTP/2 implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M21 and 8.5.0 to 8.5.15 bypassed a number of security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using a specially crafted URL.