Search Results (Refine Search)
- Keyword (text search): cpe:2.3:a:apache:tomcat:10.0.0:milestone3:*:*:*:*:*:*
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2021-25329 |
The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. Published: March 01, 2021; 7:15:14 AM -0500 |
V3.1: 7.0 HIGH V2.0: 4.4 MEDIUM |
CVE-2021-25122 |
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. Published: March 01, 2021; 7:15:13 AM -0500 |
V3.1: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2021-24122 |
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. Published: January 14, 2021; 10:15:13 AM -0500 |
V3.1: 5.9 MEDIUM V2.0: 4.3 MEDIUM |
CVE-2020-17527 |
While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests. Published: December 03, 2020; 2:15:12 PM -0500 |
V3.1: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2020-13943 |
If an HTTP/2 client connecting to Apache Tomcat 10.0.0-M1 to 10.0.0-M7, 9.0.0.M1 to 9.0.37 or 8.5.0 to 8.5.57 exceeded the agreed maximum number of concurrent streams for a connection (in violation of the HTTP/2 protocol), it was possible that a subsequent request made on that connection could contain HTTP headers - including HTTP/2 pseudo headers - from a previous request rather than the intended headers. This could lead to users seeing responses for unexpected resources. Published: October 12, 2020; 10:15:12 AM -0400 |
V3.1: 4.3 MEDIUM V2.0: 4.0 MEDIUM |
CVE-2020-13935 |
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. Published: July 14, 2020; 11:15:11 AM -0400 |
V3.1: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2020-13934 |
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. Published: July 14, 2020; 11:15:11 AM -0400 |
V3.1: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2020-11996 |
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. Published: June 26, 2020; 1:15:10 PM -0400 |
V3.1: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2020-9484 |
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. Published: May 20, 2020; 3:15:09 PM -0400 |
V3.1: 7.0 HIGH V2.0: 4.4 MEDIUM |