CVSS: 6.5EPSS: 0%CPEs: 50EXPL: 1CVE-2018-1305 – tomcat: Late application of security constraints can lead to resource exposure for unauthorised users
https://notcve.org/view.php?id=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. Las restricciones de seguridad definidas por anotaciones en Servlets en Apache Tomcat 9.0.0.M1 a 9.0.4, 8.5.0 a 8.5.27, 8.0.0.RC1 a 8.0.49 y 7.0.0 a 7.0.84 solo se aplicaban una vez se haya cargado el Servlet. Debido a que las restricciones de seguridad definidas de esta forma se aplican al patrón URL y a cualquier URL bajo ese punto, era posible (dependiendo del orden en el qe se cargan los Servlets) que no se aplicasen algunas restricciones de seguridad. • https://github.com/Pa55w0rd/CVE-2018-1305 http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html http://www.securityfocus.com/bid/103144 http://www.securitytracker.com/id/1040428 https://access.redhat.com/errata/RHSA-2018:0465 https://access.redhat.com/errata/RHSA-2018:0466 https://access.redhat.com/errata/RHSA-2018:1320 https://access.redhat.com/errata/RHSA-2018:2939 https://access.redha • CWE-284: Improper Access Control •
CVSS: 5.3EPSS: 0%CPEs: 13EXPL: 0CVE-2017-15706
https://notcve.org/view.php?id=CVE-2017-15706
As part of the fix for bug 61201, the documentation for Apache Tomcat 9.0.0.M22 to 9.0.1, 8.5.16 to 8.5.23, 8.0.45 to 8.0.47 and 7.0.79 to 7.0.82 included an updated description of the search algorithm used by the CGI Servlet to identify which script to execute. The update was not correct. As a result, some scripts may have failed to execute as expected and other scripts may have been executed unexpectedly. Note that the behaviour of the CGI servlet has remained unchanged in this regard. It is only the documentation of the behaviour that was wrong and has been corrected. • http://www.securityfocus.com/bid/103069 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/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/ • CWE-358: Improperly Implemented Security Check for Standard •
CVSS: 8.1EPSS: 97%CPEs: 175EXPL: 10CVE-2017-12617 – Apache Tomcat Remote Code Execution Vulnerability
https://notcve.org/view.php?id=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. Al ejecutar Apache Tomcat desde la versión 9.0.0.M1 hasta la 9.0.0, desde la 8.5.0 hasta la 8.5.22, desde la 8.0.0.RC1 hasta la 8.0.46 y desde la 7.0.0 hasta la 7.0.81 con los HTTP PUT habilitados (por ejemplo, configurando el parámetro de inicialización de solo lectura del servlet Default a "false"), es posible subir un archivo JSP al servidor mediante una petición especialmente manipulada. Este JSP se puede después solicitar y cualquier código que contenga se ejecutaría por el servidor. A vulnerability was discovered in Tomcat where if a servlet context was configured with readonly=false and HTTP PUT requests were allowed, an attacker could upload a JSP file to that context and achieve code execution. • https://www.exploit-db.com/exploits/43008 https://www.exploit-db.com/exploits/42966 https://github.com/cyberheartmi9/CVE-2017-12617 https://github.com/ygouzerh/CVE-2017-12617 https://github.com/LongWayHomie/CVE-2017-12617 https://github.com/yZ1337/CVE-2017-12617 https://github.com/qiantu88/CVE-2017-12617 https://github.com/devcoinfet/CVE-2017-12617 https://github.com/scirusvulgaris/CVE-2017-12617 https://github.com/K3ysTr0K3R/CVE-2017-12617-EXPLOIT http://www.oracle.com • CWE-20: Improper Input Validation CWE-434: Unrestricted Upload of File with Dangerous Type •
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: 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 •