Page 2 of 66 results (0.027 seconds)

CVSS: 6.1EPSS: 0%CPEs: 15EXPL: 1

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in FORM authentication feature Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.0.12, from 9.0.0-M1 through 9.0.79 and from 8.5.0 through 8.5.92. The vulnerability is limited to the ROOT (default) web application. Vulnerabilidad de redirección de URL a sitio no fiable ('Open Redirect') en la función de autenticación FORM de Apache Tomcat. Este problema afecta a Apache Tomcat: de 11.0.0-M1 a 11.0.0-M10, de 10.1.0-M1 a 10.0.12, de 9.0.0-M1 a 9.0.79 y de 8.5.0 a 8.5.92. La vulnerabilidad se limita a la aplicación web ROOT (por defecto). A flaw was found in Apache Tomcat if the default web application is configured with FormAuthenticator. • https://github.com/shiomiyan/CVE-2023-41080 https://lists.apache.org/thread/71wvwprtx2j2m54fovq9zr7gbm2wow2f https://lists.debian.org/debian-lts-announce/2023/10/msg00020.html https://security.netapp.com/advisory/ntap-20230921-0006 https://www.debian.org/security/2023/dsa-5521 https://www.debian.org/security/2023/dsa-5522 https://access.redhat.com/security/cve/CVE-2023-41080 https://bugzilla.redhat.com/show_bug.cgi?id=2235370 • CWE-601: URL Redirection to Untrusted Site ('Open Redirect') •

CVSS: 4.3EPSS: 0%CPEs: 5EXPL: 0

When using the RemoteIpFilter with requests received from a reverse proxy via HTTP that include the X-Forwarded-Proto header set to https, session cookies created by Apache Tomcat 11.0.0-M1 to 11.0.0.-M2, 10.1.0-M1 to 10.1.5, 9.0.0-M1 to 9.0.71 and 8.5.0 to 8.5.85 did not include the secure attribute. This could result in the user agent transmitting the session cookie over an insecure channel. When using the RemoteIpFilter with requests received from a reverse proxy via HTTP that include the X-Forwarded-Proto header set to https, session cookies created by Apache Tomcat 11.0.0-M1 to 11.0.0.-M2, 10.1.0-M1 to 10.1.5, 9.0.0-M1 to 9.0.71 and 8.5.0 to 8.5.85 did not include the secure attribute. This could result in the user agent transmitting the session cookie over an insecure channel. • https://lists.apache.org/thread/hdksc59z3s7tm39x0pp33mtwdrt8qr67 https://access.redhat.com/security/cve/CVE-2023-28708 https://bugzilla.redhat.com/show_bug.cgi?id=2180856 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-523: Unprotected Transport of Credentials •

CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0

If Apache Tomcat 8.5.0 to 8.5.82, 9.0.0-M1 to 9.0.67, 10.0.0-M1 to 10.0.26 or 10.1.0-M1 to 10.1.0 was configured to ignore invalid HTTP headers via setting rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did not reject a request containing an invalid Content-Length header making a request smuggling attack possible if Tomcat was located behind a reverse proxy that also failed to reject the request with the invalid header. Si Apache Tomcat 8.5.0 a 8.5.82, 9.0.0-M1 a 9.0.67, 10.0.0-M1 a 10.0.26 o 10.1.0-M1 a 10.1.0 se configuró para ignorar encabezados HTTP no válidos mediante la configuración de rechazarIllegalHeader a falso (el valor predeterminado solo para 8.5.x), Tomcat no rechazó una solicitud que contenía un encabezado Content-Length no válido, lo que hace posible un ataque de contrabando de solicitudes si Tomcat estaba ubicado detrás de un proxy inverso que tampoco rechazó la solicitud con el encabezado no válido. A flaw was found in Apache Tomcat. If the server is configured to ignore invalid HTTP headers, the server does not reject a request containing an invalid content-length header, making it vulnerable to a request smuggling attack. • https://lists.apache.org/thread/zzcxzvqfdqn515zfs3dxb7n8gty589sq https://security.gentoo.org/glsa/202305-37 https://access.redhat.com/security/cve/CVE-2022-42252 https://bugzilla.redhat.com/show_bug.cgi?id=2141329 • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •

CVSS: 3.7EPSS: 0%CPEs: 17EXPL: 0

The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug in Apache Tomcat 10.1.0 to 10.1.0-M12, 10.0.0-M1 to 10.0.18, 9.0.0-M1 to 9.0.60 and 8.5.0 to 8.5.77 that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client. Una implementación simplificada de lecturas y escrituras de bloqueo introducida en Tomcat versión 10 y retrocedida a Tomcat versión 9.0.47 en adelante expuso un error de concurrencia de larga data (pero extremadamente difícil de activar) en Apache Tomcat versiones 10.1.0 a 10. 1.0-M12, 10.0.0-M1 a 10.0.18, 9.0.0-M1 a 9.0.60 y 8.5.0 a 8.5.77, que podía causar que las conexiones de los clientes compartieran una instancia de Http11Processor resultando en que las respuestas, o parte de ellas, fueran recibidas por el cliente equivocado • http://www.openwall.com/lists/oss-security/2022/09/28/1 https://lists.apache.org/thread/3jjqbsp6j88b198x5rmg99b1qr8ht3g3 https://lists.debian.org/debian-lts-announce/2022/10/msg00029.html https://www.debian.org/security/2022/dsa-5265 https://access.redhat.com/security/cve/CVE-2021-43980 https://bugzilla.redhat.com/show_bug.cgi?id=2130599 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

CVSS: 8.6EPSS: 0%CPEs: 3EXPL: 0

If a web application sends a WebSocket message concurrently with the WebSocket connection closing when running on Apache Tomcat 8.5.0 to 8.5.75 or Apache Tomcat 9.0.0.M1 to 9.0.20, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors. Si una aplicación web envía un mensaje WebSocket simultáneamente con el cierre de la conexión WebSocket cuando es ejecutado en Apache Tomcat versiones 8.5.0 a 8.5.75 o Apache Tomcat versiones 9.0.0.M1 a 9.0.20, es posible que la aplicación siga usando el socket después de que se haya cerrado. El manejo de errores que es activado en este caso podría causar que el objeto agrupado sea colocado en el pool dos veces. • https://lists.apache.org/thread/6ckmjfb1k61dyzkto9vm2k5jvt4o7w7c https://security.netapp.com/advisory/ntap-20220629-0003 https://www.oracle.com/security-alerts/cpujul2022.html https://access.redhat.com/security/cve/CVE-2022-25762 https://bugzilla.redhat.com/show_bug.cgi?id=2085304 • CWE-226: Sensitive Information in Resource Not Removed Before Reuse CWE-404: Improper Resource Shutdown or Release •