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 •
CVSS: 7.5EPSS: 83%CPEs: 31EXPL: 0CVE-2017-5650
https://notcve.org/view.php?id=CVE-2017-5650
In Apache Tomcat 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, the handling of an HTTP/2 GOAWAY frame for a connection did not close streams associated with that connection that were currently waiting for a WINDOW_UPDATE before allowing the application to write more data. These waiting streams each consumed a thread. A malicious client could therefore construct a series of HTTP/2 requests that would consume all available processing threads. En Apache Tomcat 9.0.0.M1 a 9.0.0.M18 y 8.5.0 a 8.5.12, el tratamiento de un marco HTTP/2 GOAWAY para una conexión que no cerró los flujos asociados con esa conexión que estaban esperando actualmente un WINDOW_UPDATE antes de permitir que la aplicación escriba más datos. Estos flujos de espera cada uno consumió un hilo. • http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html http://www.securityfocus.com/bid/97531 http://www.securitytracker.com/id/1038217 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/th • CWE-404: Improper Resource Shutdown or Release •