Search Results (Refine Search)
- Keyword (text search): cpe:2.3:a:apache:tomcat:9.0.0:milestone20:*:*:*:*:*:*
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2018-1336 |
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. Published: August 02, 2018; 10:29:00 AM -0400 |
V4.0:(not available) V3.1: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2018-8034 |
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. Published: August 01, 2018; 2:29:00 PM -0400 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2018-1304 |
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. Published: February 28, 2018; 3:29:00 PM -0500 |
V4.0:(not available) V3.0: 5.9 MEDIUM V2.0: 4.3 MEDIUM |
CVE-2018-1305 |
Security constraints defined by annotations of Servlets 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 were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them. Published: February 23, 2018; 6:29:00 PM -0500 |
V4.0:(not available) V3.0: 6.5 MEDIUM V2.0: 4.0 MEDIUM |
CVE-2017-12617 |
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. Published: October 03, 2017; 9:29:02 PM -0400 |
V4.0:(not available) V3.0: 8.1 HIGH V2.0: 6.8 MEDIUM |
CVE-2017-7675 |
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. Published: August 10, 2017; 10:29:00 PM -0400 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2017-7674 |
The CORS Filter in Apache Tomcat 9.0.0.M1 to 9.0.0.M21, 8.5.0 to 8.5.15, 8.0.0.RC1 to 8.0.44 and 7.0.41 to 7.0.78 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. Published: August 10, 2017; 10:29:00 PM -0400 |
V4.0:(not available) V3.0: 4.3 MEDIUM V2.0: 4.3 MEDIUM |
CVE-2017-5664 |
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 HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 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. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method. Published: June 06, 2017; 10:29:00 AM -0400 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |