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 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.

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.

Improper Input Validation vulnerability.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.

The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected. Tomcat did not validate that the host name provided via the SNI extension was the same as the host name provided in the HTTP host header field. If Tomcat was configured with more than one virtual host and the TLS configuration for one of those hosts did not require client certificate authentication but another one did, it was possible for a client to bypass the client certificate authentication by sending different host names in the SNI extension and the HTTP host header field.

The vulnerability only applies if client certificate authentication is only enforced at the Connector. It does not apply if client certificate authentication is enforced at the web application.

Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.

Improper Input Validation vulnerability in Apache Tomcat.

Tomcat did not limit HTTP/0.9 requests to the GET method. If a security constraint was configured to allow HEAD requests to a URI but deny GET requests, the user could bypass that constraint on GET requests by sending a (specification invalid) HEAD request using HTTP/0.9.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0.M1 through 9.0.112.

Older, EOL versions are also affected.

Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue.

Session Fixation vulnerability in Apache Tomcat via rewrite valve.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105. Older, EOL versions may also be affected.

Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.

Apache Tomcat through versions 7.0.88, 8.0.52, 8.5.31 and 9.0.8 have defaults settings for the CORS filter that are insecure and enable 'supportsCredentials' for all origins.

Upstream announcement:

https://lists.apache.org/thread.html/fbfb713e4f8a4c0f81089b89450828011343593800cae3fb629192b1@%3Cannounce.tomcat.apache.org%3E

Upstream bug:

https://bz.apache.org/bugzilla/showbug.cgi?id=62343

Upstream Patches:

http://svn.apache.org/viewvc?view=rev&rev=1831726 / trunk/9.0 http://svn.apache.org/viewvc?view=rev&rev=1831728 / 8.5 http://svn.apache.org/viewvc?view=rev&rev=1831729 / 8.0 http://svn.apache.org/viewvc?view=rev&rev=1831730 / 7.0

External References:

http://tomcat.apache.org/security-9.html#FixedinApacheTomcat9.0.9 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.32 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.53 http://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.89

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

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

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

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

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

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

The following flaw was found in Tomcat:

When a SecurityManager is configured, a web application's ability to read system properties should be controlled by the SecurityManager. Tomcat's 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.

Upstream patches:

6.0.47: https://svn.apache.org/viewvc?view=revision&revision=1754733 7.0.72: https://svn.apache.org/viewvc?view=revision&revision=1754728 8.5.5: https://svn.apache.org/viewvc?view=revision&revision=1754726 8.0.37: https://svn.apache.org/viewvc?view=revision&revision=1754727

External References:

https://tomcat.apache.org/security-6.html#FixedinApacheTomcat6.0.47 https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.72 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.5and8.0.37

ResourceLinkFactory.setGlobalContext() is a public method and was accessible by web applications running under a security manager without any checks. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications.

External references:

http://seclists.org/bugtraq/2016/Feb/147

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.

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.

Session fixation vulnerability in Apache Tomcat 7.x before 7.0.66, 8.x before 8.0.30, and 9.x before 9.0.0.M2, when different session settings are used for deployments of multiple versions of the same web application, might allow remote attackers to hijack web sessions by leveraging use of a requestedSessionSSL field for an unintended request, related to CoyoteAdapter.java and Request.java.

The (1) Manager and (2) Host Manager applications in Apache Tomcat 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 establish sessions and send CSRF tokens for arbitrary new requests, which allows remote attackers to bypass a CSRF protection mechanism by using a token.

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.

A flaw was found in Apache Tomcat. When responding to new h2c connection requests, Apache Tomcat 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. The highest threat from this vulnerability is to data confidentiality.

A specially crafted sequence of HTTP/2 requests 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.

Reference: https://tomcat.apache.org/security-8.html

The following flaw was reported in Tomcat:

The ResourceLinkFactory 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.

Upstream patches:

6.0.47: https://svn.apache.org/viewvc?view=revision&revision=1757285 7.0.72: https://svn.apache.org/viewvc?view=revision&revision=1757275 8.5.5: https://svn.apache.org/viewvc?view=revision&revision=1757272 8.0.37: https://svn.apache.org/viewvc?view=revision&revision=1757273

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 a malicious web application was able to bypass a configured SecurityManager via a Tomcat utility method that was accessible to web applications.

The following flaw was found in Tomcat:

The Realm implementations 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.

Upstream patches:

6.0.47: https://svn.apache.org/viewvc?view=revision&revision=1758506 7.0.72: https://svn.apache.org/viewvc?view=revision&revision=1758502 8.5.5: https://svn.apache.org/viewvc?view=revision&revision=1758500 8.0.37: https://svn.apache.org/viewvc?view=revision&revision=1758501

External References:

https://tomcat.apache.org/security-6.html#FixedinApacheTomcat6.0.47 https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.72 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.5and8.0.37

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.

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.

Last updated 2 August 2024