Total
211 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-1938 | 7 Apache, Blackberry, Debian and 4 more | 21 Geode, Tomcat, Good Control and 18 more | 2024-07-24 | 7.5 HIGH | 9.8 CRITICAL |
| 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 with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later will need to make small changes to their configurations. | |||||
| CVE-2017-12615 | 4 Apache, Microsoft, Netapp and 1 more | 23 Tomcat, Windows, 7-mode Transition Tool and 20 more | 2024-07-16 | 6.8 MEDIUM | 8.1 HIGH |
| When running Apache Tomcat 7.0.0 to 7.0.79 on Windows with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default 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. | |||||
| CVE-2017-12617 | 6 Apache, Canonical, Debian and 3 more | 58 Tomcat, Ubuntu Linux, Debian Linux and 55 more | 2024-07-16 | 6.8 MEDIUM | 8.1 HIGH |
| 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. | |||||
| CVE-2023-46589 | 1 Apache | 1 Tomcat | 2024-07-12 | N/A | 7.5 HIGH |
| Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82 and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy. Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue. | |||||
| CVE-2016-8735 | 6 Apache, Canonical, Debian and 3 more | 19 Tomcat, Ubuntu Linux, Debian Linux and 16 more | 2024-06-27 | 7.5 HIGH | 9.8 CRITICAL |
| Remote code execution is possible with Apache Tomcat before 6.0.48, 7.x before 7.0.73, 8.x before 8.0.39, 8.5.x before 8.5.7, and 9.x before 9.0.0.M12 if JmxRemoteLifecycleListener is used and an attacker can reach JMX ports. The issue exists because this listener wasn't updated for consistency with the CVE-2016-3427 Oracle patch that affected credential types. | |||||
| CVE-2023-44487 | 32 Akka, Amazon, Apache and 29 more | 311 Http Server, Opensearch Data Prepper, Apisix and 308 more | 2024-06-27 | N/A | 7.5 HIGH |
| The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. | |||||
| CVE-2013-6357 | 1 Apache | 1 Tomcat | 2024-05-17 | 6.8 MEDIUM | N/A |
| Cross-site request forgery (CSRF) vulnerability in the Manager application in Apache Tomcat 5.5.25 and earlier allows remote attackers to hijack the authentication of administrators for requests that manipulate application deployment via the POST method, as demonstrated by a /manager/html/undeploy?path= URI. NOTE: the vendor disputes the significance of this report, stating that "the Apache Tomcat Security team has not accepted any reports of CSRF attacks against the Manager application ... as they require a reckless system administrator. | |||||
| CVE-2013-2185 | 2 Apache, Redhat | 3 Tomcat, Jboss Enterprise Application Platform, Jboss Enterprise Portal Platform | 2024-05-17 | 7.5 HIGH | N/A |
| The readObject method in the DiskFileItem class in Apache Tomcat and JBoss Web, as used in Red Hat JBoss Enterprise Application Platform 6.1.0 and Red Hat JBoss Portal 6.0.0, allows remote attackers to write to arbitrary files via a NULL byte in a file name in a serialized instance, a similar issue to CVE-2013-2186. NOTE: this issue is reportedly disputed by the Apache Tomcat team, although Red Hat considers it a vulnerability. The dispute appears to regard whether it is the responsibility of applications to avoid providing untrusted data to be deserialized, or whether this class should inherently protect against this issue | |||||
| CVE-2013-0346 | 1 Apache | 1 Tomcat | 2024-05-17 | 2.1 LOW | N/A |
| Apache Tomcat 7.x uses world-readable permissions for the log directory and its files, which might allow local users to obtain sensitive information by reading a file. NOTE: One Tomcat distributor has stated "The tomcat log directory does not contain any sensitive information." | |||||
| CVE-2023-28709 | 3 Apache, Debian, Netapp | 3 Tomcat, Debian Linux, 7-mode Transition Tool | 2024-02-16 | N/A | 7.5 HIGH |
| The fix for CVE-2023-24998 was incomplete for Apache Tomcat 11.0.0-M2 to 11.0.0-M4, 10.1.5 to 10.1.7, 9.0.71 to 9.0.73 and 8.5.85 to 8.5.87. If non-default HTTP connector settings were used such that the maxParameterCount could be reached using query string parameters and a request was submitted that supplied exactly maxParameterCount parameters in the query string, the limit for uploaded request parts could be bypassed with the potential for a denial of service to occur. | |||||
| CVE-2024-21733 | 1 Apache | 1 Tomcat | 2024-02-16 | N/A | 5.3 MEDIUM |
| Generation of Error Message Containing Sensitive Information vulnerability in Apache Tomcat.This issue affects Apache Tomcat: from 8.5.7 through 8.5.63, from 9.0.0-M11 through 9.0.43. Users are recommended to upgrade to version 8.5.64 onwards or 9.0.44 onwards, which contain a fix for the issue. | |||||
| CVE-2023-42794 | 1 Apache | 1 Tomcat | 2023-12-11 | N/A | 5.9 MEDIUM |
| Incomplete Cleanup vulnerability in Apache Tomcat. The internal fork of Commons FileUpload packaged with Apache Tomcat 9.0.70 through 9.0.80 and 8.5.85 through 8.5.93 included an unreleased, in progress refactoring that exposed a potential denial of service on Windows if a web application opened a stream for an uploaded file but failed to close the stream. The file would never be deleted from disk creating the possibility of an eventual denial of service due to the disk being full. Users are recommended to upgrade to version 9.0.81 onwards or 8.5.94 onwards, which fixes the issue. | |||||
| CVE-2016-6794 | 6 Apache, Canonical, Debian and 3 more | 14 Tomcat, Ubuntu Linux, Debian Linux and 11 more | 2023-12-08 | 5.0 MEDIUM | 5.3 MEDIUM |
| 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. | |||||
| CVE-2018-8037 | 2 Apache, Debian | 2 Tomcat, Debian Linux | 2023-12-08 | 4.3 MEDIUM | 5.9 MEDIUM |
| 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. | |||||
| CVE-2016-0762 | 6 Apache, Canonical, Debian and 3 more | 15 Tomcat, Ubuntu Linux, Debian Linux and 12 more | 2023-12-08 | 4.3 MEDIUM | 5.9 MEDIUM |
| 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. | |||||
| CVE-2016-0714 | 3 Apache, Canonical, Debian | 3 Tomcat, Ubuntu Linux, Debian Linux | 2023-12-08 | 6.5 MEDIUM | 8.8 HIGH |
| 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. | |||||
| CVE-2017-7675 | 1 Apache | 1 Tomcat | 2023-12-08 | 5.0 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2018-1304 | 5 Apache, Canonical, Debian and 2 more | 11 Tomcat, Ubuntu Linux, Debian Linux and 8 more | 2023-12-08 | 4.3 MEDIUM | 5.9 MEDIUM |
| The URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected. | |||||
| CVE-2016-6816 | 1 Apache | 1 Tomcat | 2023-12-08 | 6.8 MEDIUM | 7.1 HIGH |
| The code in Apache Tomcat 9.0.0.M1 to 9.0.0.M11, 8.5.0 to 8.5.6, 8.0.0.RC1 to 8.0.38, 7.0.0 to 7.0.72, and 6.0.0 to 6.0.47 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 and/or obtain sensitive information from requests other then their own. | |||||
| CVE-2016-6797 | 6 Apache, Canonical, Debian and 3 more | 14 Tomcat, Ubuntu Linux, Debian Linux and 11 more | 2023-12-08 | 5.0 MEDIUM | 7.5 HIGH |
| 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. | |||||