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.
The default servlet (org.apache.catalina.servlets.DefaultServlet) in Tomcat 4.0.4 and 4.1.10 and earlier allows remote attackers to read source code for server files via a direct request to the servlet.
Recommended action: Upgrade to 4.1.12 or 4.0.5 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 4.0.3, and possibly other versions before 4.1.3 beta, allows remote attackers to cause a denial of service (resource exhaustion) via a large number of requests to the server with null characters, which causes the working threads to hang.
Recommended action: Upgrade to 4.1.3-beta (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Tomcat may be started without proper security settings if errors are encountered while reading the web.xml file, which could allow attackers to bypass intended restrictions.
Recommended action: Upgrade to 4.0b7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jakarta Tomcat 4.0.1 allows remote attackers to reveal physical path information by requesting a long URL with a .JSP extension.
Recommended action: Upgrade to 4.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Catalina org.apache.catalina.connector.http package in Tomcat 4.0.x up to 4.0.6 allows remote attackers to cause a denial of service via several requests that do not follow the HTTP protocol, which causes Tomcat to reject later requests.
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jakarta Tomcat before 3.3.1a, when used with JDK 1.3.1 or earlier, uses trusted privileges when processing the web.xml file, which could allow remote attackers to read portions of some files through the web.xml file.
Recommended action: Upgrade to 3.3.1a (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple cross-site scripting (XSS) vulnerabilities in the (1) examples and (2) ROOT web applications for Jakarta Tomcat 3.x through 3.3.1a allow remote attackers to insert arbitrary web script or HTML.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jakarta Tomcat before 3.3.1a on certain Windows systems may allow remote attackers to cause a denial of service (thread hang and resource consumption) via a request for a JSP page containing an MS-DOS device name, such as aux.jsp.
Recommended action: Upgrade to 3.3.1a (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jakarta Tomcat before 3.3.1a, when used with JDK 1.3.1 or earlier, allows remote attackers to list directories even with an index.html or other file present, or obtain unprocessed source code for a JSP file, via a URL containing a null character.
Recommended action: Upgrade to 3.3.1a (pre-release) or later, 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.
7.0.10510.0.0-M79.0.378.5.57· Vendor fix available
Issue
The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.
Recommended action: Upgrade to 10.0.0-M7 (pre-release), 9.0.37, 8.5.57 or 7.0.105 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An h2c direct connection to Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56 did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service.
Recommended action: Upgrade to 10.0.0-M6 (pre-release), 9.0.36 or 8.5.56 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 bug CVE-2020-9484 introduced a time of check time of use vulnerability into Apache Tomcat 10.1.0-M1 to 10.1.0-M8, 10.0.0-M5 to 10.0.14, 9.0.35 to 9.0.56 and 8.5.55 to 8.5.73 that allowed a local attacker to perform actions with the privileges of the user that the Tomcat process is using. This issue is only exploitable when Tomcat is configured to persist sessions using the FileStore.
Recommended action: Upgrade to 10.0.16, 9.0.58 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.
9.0.5410.1.0-M68.5.7210.0.12· Vendor fix available
Issue
The fix for bug 63362 present in Apache Tomcat 10.1.0-M1 to 10.1.0-M5, 10.0.0-M1 to 10.0.11, 9.0.40 to 9.0.53 and 8.5.60 to 8.5.71 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.
Recommended action: Upgrade to 10.1.0-M6 (pre-release), 10.0.12, 9.0.54 or 8.5.72 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 8.5.0 to 8.5.63, 9.0.0-M1 to 9.0.43 and 10.0.0-M1 to 10.0.2 did not properly validate incoming TLS packets. When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be used to trigger an infinite loop resulting in a denial of service.
Recommended action: Upgrade to 10.0.4, 9.0.44 or 8.5.64 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 10.0.5, 9.0.45 or 8.5.65 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 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.
Recommended action: Upgrade to 10.0.7, 9.0.48 or 8.5.68 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64.
Recommended action: Upgrade to 10.0.5, 9.0.45 or 8.5.65 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.
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.
MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in Apache Tomcat, JBoss Web, and other products, allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted Content-Type header that bypasses a loop's intended exit conditions.
Recommended action: Upgrade to 8.0.3 or 7.0.52 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.