Page 4 of 70 results (0.008 seconds)

CVSS: 5.5EPSS: 0%CPEs: 73EXPL: 0

When reading a specially crafted TAR archive an Apache Ant build can be made to allocate large amounts of memory that finally leads to an out of memory error, even for small inputs. This can be used to disrupt builds using Apache Ant. Apache Ant prior to 1.9.16 and 1.10.11 were affected. Cuando se lee un archivo TAR especialmente diseñado, se puede hacer que una compilación de Apache Ant asigne grandes cantidades de memoria que finalmente conlleva a un error de falta de memoria, incluso para entradas pequeñas. Esto puede ser usado para interrumpir las compilaciones usando Apache Ant. • https://ant.apache.org/security.html https://lists.apache.org/thread.html/r27919fd4db07c487239c1d9771f480d89ce5ee2750aa9447309b709a%40%3Ccommits.groovy.apache.org%3E https://lists.apache.org/thread.html/r544c9e8487431768465b8b2d13982c75123109bd816acf839d46010d%40%3Ccommits.groovy.apache.org%3E https://lists.apache.org/thread.html/r54afdab05e01de970649c2d91a993f68a6b00cd73e6e34e16c832d46%40%3Cuser.ant.apache.org%3E https://lists.apache.org/thread.html/rad36f470647c5a7c02dd78c9973356d2840766d132b597b6444e373a%40%3Cnotifications.groovy.apache.org%3E https://lists.apache.org/thre • 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: 5.8EPSS: 0%CPEs: 136EXPL: 1

In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value. En Apache Commons IO versiones anteriores a 2.7, Cuando se invoca el método FileNameUtils.normalize con una cadena de entrada inapropiada, como "//../foo" o "\\..\ foo", el resultado sería el mismo valor, por lo que posiblemente proporcionar acceso a archivos en el directorio principal, pero no más arriba (por lo tanto, salto de ruta "limited"), si el código de llamada usara el resultado para construir un valor de ruta • https://issues.apache.org/jira/browse/IO-556 https://lists.apache.org/thread.html/r01b4a1fcdf3311c936ce33d75a9398b6c255f00c1a2f312ac21effe1%40%3Cnotifications.zookeeper.apache.org%3E https://lists.apache.org/thread.html/r0bfa8f7921abdfae788b1f076a12f73a92c93cc0a6e1083bce0027c5%40%3Cnotifications.zookeeper.apache.org%3E https://lists.apache.org/thread.html/r0d73e2071d1f1afe1a15da14c5b6feb2cf17e3871168d5a3c8451436%40%3Ccommits.pulsar.apache.org%3E https://lists.apache.org/thread.html/r1c2f4683c35696cf6f863e3c107e37ec41305b1930dd40c17260de71%40%3Ccommits.pulsar.apache.org%3E https:/ • CWE-20: Improper Input Validation CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •

CVSS: 7.0EPSS: 0%CPEs: 60EXPL: 0

The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. La corrección para el CVE-2020-9484 estaba incompleta. Cuando se usa Apache Tomcat versiones 10.0.0-M1 hasta 10.0.0, versiones 9.0.0.M1 hasta 9.0.41, versiones 8.5.0 hasta 8.5.61 o versiones 7.0.0. • http://www.openwall.com/lists/oss-security/2021/03/01/2 https://lists.apache.org/thread.html/r11ce01e8a4c7269b88f88212f21830edf73558997ac7744f37769b77%40%3Cusers.tomcat.apache.org%3E https://lists.apache.org/thread.html/r732b2ca289dc02df2de820e8775559abd6c207f159e39f559547a085%40%3Cusers.tomcat.apache.org%3E https://lists.apache.org/thread.html/r8a2ac0e476dbfc1e6440b09dcc782d444ad635d6da26f0284725a5dc%40%3Cusers.tomcat.apache.org%3E https://lists.apache.org/thread.html/rb51ccd58b2152fc75125b2406fc93e04ca9d34e737263faa6ff0f41f%40%3Cusers.tomcat.apache.org%3E https:/ • CWE-502: Deserialization of Untrusted Data •

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

When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. Cuando se responde a nuevas peticiones de conexión h2c, Apache Tomcat versiones 10.0.0-M1 hasta 10.0.0, versiones 9.0.0.M1 hasta 9.0.41 y versiones 8.5.0 hasta 8.5.61, podrían duplicar los encabezados de petición y una cantidad limitada del cuerpo de petición de una petición a otra, lo que significa que el usuario A y el usuario B podrían visualizar los resultados de la petición del usuario A A flaw was found in Apache Tomcat. When responding to new h2c connection requests, Apache Tomcat could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. The highest threat from this vulnerability is to data confidentiality. • http://www.openwall.com/lists/oss-security/2021/03/01/1 https://lists.apache.org/thread.html/r7b95bc248603360501f18c8eb03bb6001ec0ee3296205b34b07105b7%40%3Cannounce.apache.org%3E https://lists.apache.org/thread.html/r7b95bc248603360501f18c8eb03bb6001ec0ee3296205b34b07105b7%40%3Cannounce.tomcat.apache.org%3E https://lists.apache.org/thread.html/r7b95bc248603360501f18c8eb03bb6001ec0ee3296205b34b07105b7%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/r7b95bc248603360501f18c8eb03bb6001ec0ee3296205b34b07105b7%40%3Cusers.tomcat.apache.org%3E https://lists • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •