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
79 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A regression in the fix for bug 66512 in Apache Tomcat 11.0.0-M5, 10.1.8, 9.0.74 and 8.5.88 meant that, if a response did not include any HTTP headers no AJP SENDHEADERS message would be sent for the response which in turn meant that at least one AJP proxy (modproxyajp) would use the response headers from the previous request leading to an information leak.
Recommended action: Upgrade to 11.0.0-M6 (pre-release), 10.1.9 or 9.0.75 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.
Recommended action: Upgrade to 11.0.0-M5 (pre-release), 10.1.5, 9.0.71 or 8.5.88 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The JsonErrorReportValve in Apache Tomcat 8.5.83, 9.0.40 to 9.0.68 and 10.1.0-M1 to 10.1.1 does not escape the type, message or description values. In some circumstances these are constructed from user provided data and it was therefore possible for users to supply values that invalidated or manipulated the JSON output.
Recommended action: Upgrade to 10.1.2, 9.0.69 or 8.5.84 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If Apache Tomcat 8.5.0 to 8.5.82, 9.0.0-M1 to 9.0.67, 10.0.0-M1 to 10.0.26 or 10.1.0-M1 to 10.1.0 was configured to ignore invalid HTTP headers via setting rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did not reject a request containing an invalid Content-Length header making a request smuggling attack possible if Tomcat was located behind a reverse proxy that also failed to reject the request with the invalid header.
Recommended action: Upgrade to 10.1.1, 10.0.27, 9.0.68 or 8.5.83 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/ajp/AbstractAjpProcessor.java in Apache Tomcat 8.x before 8.0.4 allows remote attackers to cause a denial of service (thread consumption) by using a "Content-Length: 0" AJP request to trigger a hang in request processing.
Recommended action: Upgrade to 8.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
Recommended action: Upgrade to 9.0.1, 8.5.23, 8.0.47 or 7.0.82 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 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.
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.
While investigating bug 60718, it was noticed that some calls to application listeners in Apache Tomcat 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75 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.
Recommended action: Upgrade to 9.0.0.M18, 8.5.13, 8.0.42 or 7.0.76 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site scripting (XSS) vulnerability in Apache Tomcat 5.5.9 through 5.5.26 and 6.0.0 through 6.0.16 allows remote attackers to inject arbitrary web script or HTML via the name parameter (aka the hostname attribute) to host-manager/html/add.
Recommended action: Upgrade to 6.0.18 or 5.5.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A specially crafted sequence of HTTP/2 requests sent to Apache Tomcat 10.0.0-M1 to 10.0.0-M5, 9.0.0.M1 to 9.0.35 and 8.5.0 to 8.5.55 could trigger high CPU usage for several seconds. If a sufficient number of such requests were made on concurrent HTTP/2 connections, the server could become unresponsive.
Recommended action: Upgrade to 10.0.0-M5 (pre-release), 9.0.35 or 8.5.55 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request.
Recommended action: Upgrade to 10.0.2, 9.0.43 or 8.5.63 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.408.5.6010.0.0-M107.0.107· Vendor fix available
Issue
When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances.
Recommended action: Upgrade to 10.0.0-M10 (pre-release), 9.0.40, 8.5.60 or 7.0.107 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: returning arbitrary files from anywhere in the web application, processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along…
Recommended action: Upgrade to 9.0.31, 8.5.51 or 7.0.100 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.14 and 8.5.0 to 8.5.37 accepted streams with excessive numbers of SETTINGS frames and also permitted clients to keep streams open without reading/writing request/response data. By keeping streams open for requests that utilised the Servlet API's blocking I/O, clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.
Recommended action: Upgrade to 9.0.16 or 8.5.38 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
8.5.557.0.10410.0.0-M59.0.35· Vendor fix available
Issue
When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed.
Recommended action: Upgrade to 10.0.0-M5 (pre-release), 9.0.35, 8.5.55 or 7.0.104 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The refactoring present in Apache Tomcat versions 9.0.28 to 9.0.30, 8.5.48 to 8.5.50 and 7.0.98 to 7.0.99 introduced a regression. The result of the regression was that invalid Transfer-Encoding headers were incorrectly processed leading to a 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. Such a reverse proxy is considered unlikely.
Recommended action: Upgrade to 9.0.31, 8.5.51 or 7.0.100 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.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99 the HTTP header parsing code used an approach to end-of-line parsing that allowed some invalid HTTP headers to be parsed as valid. This led to a 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. Such a reverse proxy is considered unlikely.
Recommended action: Upgrade to 9.0.31, 8.5.51 or 7.0.100 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using FORM authentication with Apache Tomcat 9.0.0.M1 to 9.0.29, 8.5.0 to 8.5.49 and 7.0.0 to 7.0.98 there was a narrow window where an attacker could perform a session fixation attack. The window was considered too narrow for an exploit to be practical but, erring on the side of caution, this issue has been treated as a security vulnerability.
Recommended action: Upgrade to 9.0.30, 8.5.50 or 7.0.99 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOWUPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.
Recommended action: Upgrade to 9.0.20 or 8.5.41 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSI printenv command in Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 echoes user provided data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website.
Recommended action: Upgrade to 9.0.17, 8.5.40 or 7.0.94 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When running on Windows with enableCmdLineArguments enabled, the CGI Servlet in Apache Tomcat 9.0.0.M1 to 9.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 is vulnerable to Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows. The CGI Servlet is disabled by default. The CGI option enableCmdLineArguments is disable by default in Tomcat 9.0.x (and will be disabled by default in all versions in response to this vulnerability). For a detailed explanation of the JRE behaviour, see Markus Wulftange's blog (https://codewhitesec.blogspot.com/2016/02/java-and-command-line-injections-in-windows.html) and this archived MSDN blog (https://web.archive.org/web/20161228144344/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/).
Recommended action: Upgrade to 9.0.17, 8.5.40 or 7.0.94 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If an async request was completed by the application at the same time as the container triggered the async timeout, a race condition existed that could result in a user seeing a response intended for a different user. An additional issue was present in the NIO and NIO2 connectors that did not correctly track the closure of the connection when an async request was completed by the application and timed out by the container at the same time. This could also result in a user seeing a response intended for another user. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.9 and 8.5.5 to 8.5.31.
Recommended action: Upgrade to 9.0.10 or 8.5.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The host name verification when using TLS with the WebSocket client was missing. It is now enabled by default. Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.9, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, and 7.0.35 to 7.0.88.
Recommended action: Upgrade to 9.0.10, 8.5.32, 8.0.53 or 7.0.90 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The defaults settings for the CORS filter provided in Apache Tomcat 9.0.0.M1 to 9.0.8, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, 7.0.41 to 7.0.88 are insecure and enable 'supportsCredentials' for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue.
Recommended action: Upgrade to 9.0.9, 8.5.32, 8.0.53 or 7.0.88 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An improper handing of overflow in the UTF-8 decoder with supplementary characters can lead to an infinite loop in the decoder causing a Denial of Service. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.7, 8.5.0 to 8.5.30, 8.0.0.RC1 to 8.0.51, and 7.0.28 to 7.0.86.
Recommended action: Upgrade to 9.0.8, 8.5.31, 8.0.51 or 7.0.87 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.