Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
147 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
java/org/apache/catalina/servlets/DefaultServlet.java in the default servlet in Apache Tomcat before 6.0.40, 7.x before 7.0.53, and 8.x before 8.0.4 does not properly restrict XSLT stylesheets, which allows remote attackers to bypass security-manager restrictions and 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.
Recommended action: Upgrade to 8.0.6, 7.0.54 or 6.0.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.6, 7.0.54 or 6.0.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.9, 7.0.55 or 6.0.42 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Tomcat 6.x before 6.0.44, 7.x before 7.0.55, and 8.x before 8.0.9 does not properly handle cases where an HTTP response occurs before finishing the reading of an entire request body, which allows remote attackers to cause a denial of service (thread consumption) via a series of aborted upload attempts.
Recommended action: Upgrade to 8.0.9, 7.0.55 or 6.0.44 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 9.0.0.M2, 8.0.31 or 6.0.45 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The session-persistence implementation in 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 mishandles session attributes, which allows remote authenticated users to bypass intended SecurityManager restrictions and execute arbitrary code in a privileged context via a web application that places a crafted object in a session.
Recommended action: Upgrade to 9.0.0.M2, 8.0.32, 7.0.70 or 6.0.46 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Expression Language (EL) implementation in Apache Tomcat 6.x before 6.0.44, 7.x before 7.0.58, and 8.x before 8.0.16 does not properly consider the possibility of an accessible interface implemented by an inaccessible class, which allows attackers to bypass a SecurityManager protection mechanism via a web application that leverages use of incorrect privileges during EL evaluation.
Recommended action: Upgrade to 8.0.16, 7.0.58 or 6.0.44 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The HTTP/2 header parser in Apache Tomcat 9.0.0.M1 to 9.0.0.M11 and 8.5.0 to 8.5.6 entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.
Recommended action: Upgrade to 9.0.0.M12 or 8.5.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 9.0.0.M2, 8.0.30, 7.0.68 or 6.0.45 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.0.0.M198.0.437.0.778.5.136.0.53· Vendor fix available
Issue
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.
Recommended action: Upgrade to 9.0.0.M19, 8.5.13, 8.0.43 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.27, 7.0.65 or 6.0.45 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The CORS Filter in Apache Tomcat 9.0.0.M1 to 9.0.0.M21, 8.5.0 to 8.5.15, 8.0.0.RC1 to 8.0.44 and 7.0.41 to 7.0.78 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.
Recommended action: Upgrade to 9.0.0.M22, 8.5.16, 8.0.45 or 7.0.79 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An information disclosure issue was discovered in Apache Tomcat 8.5.7 to 8.5.9 and 9.0.0.M11 to 9.0.0.M15 in reverse-proxy configurations. Http11InputBuffer.java allows remote attackers to read data that was intended to be associated with a different request.
Recommended action: Upgrade to 9.0.0.M16 or 8.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
As part of the fix for bug 61201, the documentation for Apache Tomcat 9.0.0.M22 to 9.0.1, 8.5.16 to 8.5.23, 8.0.45 to 8.0.47 and 7.0.79 to 7.0.82 included an updated description of the search algorithm used by the CGI Servlet to identify which script to execute. The update was not correct. As a result, some scripts may have failed to execute as expected and other scripts may have been executed unexpectedly. Note that the behaviour of the CGI servlet has remained unchanged in this regard. It is only the documentation of the behaviour that was wrong and has been corrected.
Recommended action: Upgrade to 9.0.2, 8.5.24, 8.0.48 or 7.0.84 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 9.0.0.M22 or 8.5.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If a web application sends a WebSocket message concurrently with the WebSocket connection closing when running on Apache Tomcat 8.5.0 to 8.5.75 or Apache Tomcat 9.0.0.M1 to 9.0.20, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors.
Recommended action: Upgrade to 9.0.20 or 8.5.75 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 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: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they…
Recommended action: Upgrade to 9.0.0.M21, 8.5.15, 8.0.44 or 7.0.78 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 9.0.0.M19 or 8.5.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 7.0.40 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
8.5.58.0.379.0.0.M106.0.467.0.71· Vendor fix available
Issue
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.
Recommended action: Upgrade to 9.0.0.M10, 8.5.5, 8.0.37 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
7.0.728.5.58.0.379.0.0.M106.0.47· Vendor fix available
Issue
When a SecurityManager is configured, a web application's ability to read system properties should be controlled by the SecurityManager. 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.0.36, 7.0.0 to 7.0.70, 6.0.0 to 6.0.45 the 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.
Recommended action: Upgrade to 9.0.0.M10, 8.5.5, 8.0.37 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ResourceLinkFactory implementation 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.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 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.
Recommended action: Upgrade to 9.0.0.M10, 8.5.5, 8.0.37 or 7.0.72 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
7.0.728.5.58.0.379.0.0.M106.0.46· Vendor fix available
Issue
The Realm implementations in Apache Tomcat versions 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 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.
Recommended action: Upgrade to 9.0.0.M10, 8.5.5, 8.0.37 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.0.6310.1.0-M1510.0.218.5.79· Vendor fix available
Issue
The documentation of Apache Tomcat 10.1.0-M1 to 10.1.0-M14, 10.0.0-M1 to 10.0.20, 9.0.13 to 9.0.62 and 8.5.38 to 8.5.78 for the EncryptInterceptor incorrectly stated it enabled Tomcat clustering to run over an untrusted network. This was not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly DoS risks.
Recommended action: Upgrade to 10.1.0-M15 (pre-release), 10.0.21, 9.0.63 or 8.5.79 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 7.0.23, 6.0.34 or 5.5.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.