CVSS: 7.5EPSS: 0%CPEs: 37EXPL: 0CVE-2017-7675
https://notcve.org/view.php?id=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. La implementación HTTP/2 en Apache Tomcat en sus versiones 9.0.0.M1 a 9.0.0.M21 y 8.5.0 a 8.5.15 eludía una serie de verificaciones de seguridad que prevenían ataques de salto de directorio. Por lo tanto, era posible eludir restricciones de seguridad empleando una URL especialmente manipulada. • http://www.debian.org/security/2017/dsa-3974 http://www.securityfocus.com/bid/100256 https://lists.apache.org/thread.html/1dd0a59c1295cc08ce4c9e7edae5ad2268acc9ba55adcefa0532e5ba%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/5c0e00fd31efc11e147bf99d0f03c00a734447d3b131ab0818644cdb%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/5f8ab8a02f3610bd56ea2b0d69af25cbde451d79c46276c350e05a15%40%3Cdev.tomcat.apache&# • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •
CVSS: 5.9EPSS: 0%CPEs: 123EXPL: 0CVE-2017-7674 – tomcat: Vary header not added by CORS filter leading to cache poisoning
https://notcve.org/view.php?id=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. CORS Filter en Apache Tomcat 9.0.0.M1 a 9.0.0.M21, 8.5.0 a 8.5.15, 8.0.0.RC1 a 8.0.44 y 7.0.41 a 7.0.78 no añadió un encabezado HTTP Vary indicando que la respuesta varía dependiendo de Origin. Esto permitía, en algunas circunstancias, el envenenamiento de la caché del lado del cliente y del servidor. A vulnerability was discovered in Tomcat where the CORS Filter did not send a "Vary: Origin" HTTP header. • http://www.debian.org/security/2017/dsa-3974 http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html http://www.securityfocus.com/bid/100280 https://access.redhat.com/errata/RHSA-2017:1801 https://access.redhat.com/errata/RHSA-2017:1802 https://access.redhat.com/errata/RHSA-2017:3081 https://lists.apache.org/thread.html/1dd0a59c1295cc08ce4c9e7edae5ad2268acc9ba55adcefa0532e5ba%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/22b4bb077502f847e2b9fcf00b96e81e734466ab459780ff73b60c0f%40% • CWE-345: Insufficient Verification of Data Authenticity •
CVSS: 7.5EPSS: 2%CPEs: 18EXPL: 0CVE-2016-6817
https://notcve.org/view.php?id=CVE-2016-6817
The HTTP/2 header parser in Apache Tomcat 9.0.0.M1 to 9.0.0.M11 and 8.5.0 to 8.5.6 entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible. El parser de cabecera HTTP/2 en Apache Tomcat en sus versiones 9.0.0.M1 a 9.0.0.M11 y 8.5.0 a 8.5.6 entraba en un bucle infinito si la cabecera recibida era mayor que el búfer disponible. Esto hizo que fuese posible realizar un ataque de denegación de servicio. • http://www.securityfocus.com/bid/94462 http://www.securitytracker.com/id/1037330 https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/a9f24571460af003071475b75f18cad81ebcc36fa7c876965a75e32a%40%3Cannounce.tomcat.apache.org&# • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: 7.5EPSS: 0%CPEs: 161EXPL: 0CVE-2017-5664 – tomcat: Security constrained bypass in error page mechanism
https://notcve.org/view.php?id=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. • http://www.debian.org/security/2017/dsa-3891 http://www.debian.org/security/2017/dsa-3892 http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html http://www.securityfocus.com/bid/98888 http://www.securitytracker.com/id/1038641 https://access.redhat.com • CWE-266: Incorrect Privilege Assignment CWE-755: Improper Handling of Exceptional Conditions •
CVSS: 7.5EPSS: 0%CPEs: 205EXPL: 0CVE-2017-5647 – tomcat: Incorrect handling of pipelined requests when send file was used
https://notcve.org/view.php?id=CVE-2017-5647
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. Un fallo en el manejo de las peticiones pipelinadas en Apache Tomcat 9.0.0.M1 a 9.0.0.M18, 8.5.0 a 8.5.12, 8.0.0.RC1 a 8.0.42, 7.0.0 a 7.0.76, Y 6.0.0 a 6.0.52, cuando se utilizó el archivo de envío, se pierde la solicitud de pipeline cuando se procesa el archivo de envío de la solicitud anterior completada. Esto podría resultar en respuestas que parecen ser enviadas para la solicitud incorrecta. • http://www.arubanetworks.com/assets/alert/HPESBHF03730.txt http://www.debian.org/security/2017/dsa-3842 http://www.debian.org/security/2017/dsa-3843 http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html http://www.securitytracker.com/id/1038218 https://access.redhat.com/errata/RHSA-2017:1801 https://access.redhat.com/errata/RHSA-2017:1802 https://access.redhat.com/errata/RHSA-2017:2493 https://access.redhat.com/errata/RHSA-2017:2494 https://access.redhat&# • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •