Page 2 of 69 results (0.012 seconds)

CVSS: 7.5EPSS: 1%CPEs: 72EXPL: 0

When reading a specially crafted ZIP archive, Compress can be made to allocate large amounts of memory that finally leads to an out of memory error even for very small inputs. This could be used to mount a denial of service attack against services that use Compress' zip package. Al leer un archivo ZIP especialmente diseñado, Compress puede asignar grandes cantidades de memoria que finalmente conllevan a un error de falta de memoria incluso para entradas muy pequeñas. Esto podría ser usado para montar un ataque de denegación de servicio contra los servicios que usan el paquete zip de Compress A flaw was found in apache-commons-compress. When reading a specially crafted ZIP archive, Compress can allocate large amounts of memory that leads to an out-of-memory error for small inputs. • http://www.openwall.com/lists/oss-security/2021/07/13/4 http://www.openwall.com/lists/oss-security/2021/07/13/6 https://commons.apache.org/proper/commons-compress/security-reports.html https://lists.apache.org/thread.html/r0e87177f8e78b4ee453cd4d3d8f4ddec6f10d2c27707dd71e12cafc9%40%3Cannounce.apache.org%3E https://lists.apache.org/thread.html/r25f4c44616045085bc3cf901bb7e68e445eee53d1966fc08998fc456%40%3Cdev.drill.apache.org%3E https://lists.apache.org/thread.html/r3227b1287e5bd8db6523b862c22676b046ad8f4fc96433225f46a2bd%40%3Cissues.drill.apache • CWE-130: Improper Handling of Length Parameter Inconsistency CWE-770: Allocation of Resources Without Limits or Throttling •

CVSS: 5.3EPSS: 10%CPEs: 42EXPL: 0

Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding. Apache Tomcat versiones 10.0.0-M1 hasta 10.0.6, versiones 9.0.0.M1 hasta 9.0.46 y versiones 8.5.0 hasta 8.5.66, no analizaban correctamente el encabezado de petición HTTP transfer-encoding en algunas circunstancias, conllevando a la posibilidad de contrabando de peticiones cuando se usaba con un proxy inverso. Específicamente: - Tomcat ignoraba incorrectamente el encabezado de codificación de transferencia si el cliente declaraba que sólo aceptaría una respuesta HTTP/1.0; - Tomcat honraba la codificación de identificación; y - Tomcat no se aseguraba de que, si estaba presente, la codificación en trozos fuera la codificación final • https://kc.mcafee.com/corporate/index?page=content&id=SB10366 https://lists.apache.org/thread.html/r290aee55b72811fd19e75ac80f6143716c079170c5671b96932ed44b%40%3Ccommits.tomee.apache.org%3E https://lists.apache.org/thread.html/r40f921575aee8d7d34e53182f862c45cbb8f3d898c9d4e865c2ec262%40%3Ccommits.tomee.apache.org%3E https://lists.apache.org/thread.html/r612a79269b0d5e5780c62dfd34286a8037232fec0bc6f1a7e60c9381%40%3Cannounce.tomcat.apache.org%3E https://lists.apache.org/thread.html/rc6ef52453bb996a98cb45442871a1db56b7c349939e45d829bf9ae37%40%3Ccommits.tomee.apache.org%3E https:/ • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •

CVSS: 3.6EPSS: 0%CPEs: 19EXPL: 0

For Eclipse Jetty versions <= 9.4.40, <= 10.0.2, <= 11.0.2, if an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts this can result in a session not being invalidated. This can result in an application used on a shared computer being left logged in. Para Eclipse Jetty versiones anteriores a 9.4.40 incluyéndola, versiones anteriores a 10.0.2 incluyéndola, versiones anteriores a 11.0.2 incluyéndola, si es lanzada una excepción desde el método SessionListener#sessionDestroyed(), el ID de sesión no es invalidado en el administrador de ID de sesión. En despliegues con sesiones agrupadas y múltiples contextos esto puede resultar en que una sesión no sea invalidada. • https://github.com/eclipse/jetty.project/security/advisories/GHSA-m6cp-vxjx-65j6 https://lists.apache.org/thread.html/r67c4f90658fde875521c949448c54c98517beecdc7f618f902c620ec%40%3Cissues.zookeeper.apache.org%3E https://lists.apache.org/thread.html/r8a1a332899a1f92c8118b0895b144b27a78e3f25b9d58a34dd5eb084%40%3Cnotifications.zookeeper.apache.org%3E https://lists.apache.org/thread.html/rbefa055282d52d6b58d29a79fbb0be65ab0a38d25f00bd29eaf5e6fd%40%3Cnotifications.zookeeper.apache.org%3E https://lists.apache.org/thread.html/rddbb4f8d5db23265bb63d14ef4b3723b438abc1589f877db11d35450%40%3Cissues.zo • CWE-613: Insufficient Session Expiration •

CVSS: 7.8EPSS: 0%CPEs: 49EXPL: 0

In Spring Framework, versions 5.2.x prior to 5.2.15 and versions 5.3.x prior to 5.3.7, a WebFlux application is vulnerable to a privilege escalation: by (re)creating the temporary storage directory, a locally authenticated malicious user can read or modify files that have been uploaded to the WebFlux application, or overwrite arbitrary files with multipart request data. En Spring Framework, versiones 5.2.x anteriores a 5.2.15 y versiones 5.3.x anteriores a 5.3.7, una aplicación WebFlux es vulnerable a una escalada de privilegios: al (re)crear el directorio de almacenamiento temporal, un usuario malicioso autenticado localmente puede leer o modificar archivos que han sido subidos a la aplicación WebFlux, o sobrescribir archivos arbitrarios con petición de datos de múltiples partes • https://security.netapp.com/advisory/ntap-20210713-0005 https://tanzu.vmware.com/security/cve-2021-22118 https://www.oracle.com//security-alerts/cpujul2021.html https://www.oracle.com/security-alerts/cpuapr2022.html https://www.oracle.com/security-alerts/cpujan2022.html https://www.oracle.com/security-alerts/cpujul2022.html https://www.oracle.com/security-alerts/cpuoct2021.html https://access.redhat.com/security/cve/CVE-2021-22118 https://bugzilla.redhat.com/show_bug.cgi?id=1974854 • CWE-269: Improper Privilege Management CWE-281: Improper Preservation of Permissions CWE-668: Exposure of Resource to Wrong Sphere •

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

CXF supports (via JwtRequestCodeFilter) passing OAuth 2 parameters via a JWT token as opposed to query parameters (see: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)). Instead of sending a JWT token as a "request" parameter, the spec also supports specifying a URI from which to retrieve a JWT token from via the "request_uri" parameter. CXF was not validating the "request_uri" parameter (apart from ensuring it uses "https) and was making a REST request to the parameter in the request to retrieve a token. This means that CXF was vulnerable to DDos attacks on the authorization server, as specified in section 10.4.1 of the spec. This issue affects Apache CXF versions prior to 3.4.3; Apache CXF versions prior to 3.3.10. • http://www.openwall.com/lists/oss-security/2021/04/02/2 https://cxf.apache.org/security-advisories.data/CVE-2021-22696.txt.asc https://lists.apache.org/thread.html/r6445001cc5f9a2bb1e6316993753306e054bdd1d702656b7cbe59045%40%3Cannounce.apache.org%3E https://lists.apache.org/thread.html/r8651c06212c56294a1c0ea61a5ad7790c06502209c03f05c0c7c9914%40%3Cdev.cxf.apache.org%3E https://lists.apache.org/thread.html/r8651c06212c56294a1c0ea61a5ad7790c06502209c03f05c0c7c9914%40%3Cusers.cxf.apache.org%3E https://lists.apache.org/thread.html/rec7160382badd3ef4ad017 • CWE-400: Uncontrolled Resource Consumption CWE-918: Server-Side Request Forgery (SSRF) •