Page 18 of 249 results (0.016 seconds)

CVSS: 3.3EPSS: 0%CPEs: 23EXPL: 1

A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured. • https://github.com/google/guava/commit/fec0dbc4634006a6162cfd4d0d09c962073ddf40 https://github.com/google/guava/issues/4011 https://lists.apache.org/thread.html/r007add131977f4f576c232b25e024249a3d16f66aad14a4b52819d21%40%3Ccommon-issues.hadoop.apache.org%3E https://lists.apache.org/thread.html/r07ed3e4417ad043a27bee7bb33322e9bfc7d7e6d1719b8e3dfd95c14%40%3Cdev.drill.apache.org%3E https://lists.apache.org/thread.html/r161b87f8037bbaff400194a63cd2016c9a69f5949f06dcc79beeab54%40%3Cdev.drill.apache.org%3E https://lists.apache.org/thread.html/r215b3d50f56faeb2f9383505f3e62faa9f549bb • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-378: Creation of Temporary File With Insecure Permissions CWE-732: Incorrect Permission Assignment for Critical Resource •

CVSS: 5.9EPSS: 0%CPEs: 75EXPL: 1

The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. • https://github.com/MBHudson/CVE-2020-1971 http://www.openwall.com/lists/oss-security/2021/09/14/2 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=2154ab83e14ede338d2ede9bbe5cdfce5d5a6c9e https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=f960d81215ebf3f65e03d4d5d857fb9b666d6920 https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44676 https://lists.apache.org/thread.html/r63c6f2dd363d9b514d0a4bcf624580616a679898cc14c109a49b7 • CWE-476: NULL Pointer Dereference •

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

Apache Groovy provides extension methods to aid with creating temporary directories. Prior to this fix, Groovy's implementation of those extension methods was using a now superseded Java JDK method call that is potentially not secure on some operating systems in some contexts. Users not using the extension methods mentioned in the advisory are not affected, but may wish to read the advisory for further details. Versions Affected: 2.0 to 2.4.20, 2.5.0 to 2.5.13, 3.0.0 to 3.0.6, and 4.0.0-alpha-1. Fixed in versions 2.4.21, 2.5.14, 3.0.7, 4.0.0-alpha-2. • https://groovy-lang.org/security.html#CVE-2020-17521 https://lists.apache.org/thread.html/r4b2f13c302eec98838ff7475253091fb9b75bc1038016ba00ebf6c08%40%3Cdev.atlas.apache.org%3E https://lists.apache.org/thread.html/ra9dab34bf8625511f23692ad0fcee2725f782e9aad6c5cdff6cf4465%40%3Cnotifications.groovy.apache.org%3E https://lists.apache.org/thread.html/rea63a4666ba245d2892471307772a2d8ce0f0741f341d6576625c1b3%40%3Cdev.atlas.apache.org%3E https://security.netapp.com/advisory/ntap-20201218-0006 https://www.oracle.com//security-alerts/cpujul2021.html https:/ • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •

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

While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests. Al investigar el error 64830, se detectó que Apache Tomcat versiones 10.0.0-M1 hasta 10.0.0-M9, versiones 9.0.0-M1 hasta 9.0.39 y versiones 8.5.0 hasta 8.5.59, podría reutilizar un valor de encabezado de petición HTTP de la transmisión anterior recibida en una conexión HTTP/2 para la petición asociada con la transmisión posterior. Si bien esto probablemente conllevaría a un error y al cierre de la conexión HTTP/2, es posible que la información podría filtrarse entre peticiones • https://github.com/forse01/CVE-2020-17527-Tomcat http://www.openwall.com/lists/oss-security/2020/12/03/3 https://lists.apache.org/thread.html/r26a2a66339087fc37db3caf201e446d3e83b5cce314371e235ff1784%40%3Ccommits.tomee.apache.org%3E https://lists.apache.org/thread.html/r2d6e05c5ff96f8068a59dfdb3800e9ee8d4e36ce1971783c6e5f9b20%40%3Ccommits.tomee.apache.org%3E https://lists.apache.org/thread.html/r5a285242737ddef4d338236328aaaf3237183e1465a5efafd16b99ed%40%3Cdev.tomcat.apache.org%3E https://lists.apache.org/thread.html/r8a227ac6a755a6406c1cc47dd48800e973d4cf13fe7f • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •

CVSS: 5.8EPSS: 1%CPEs: 27EXPL: 0

In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request. En Eclipse Jetty versión 9.4.0.RC0 hasta 9.4.34.v20201102, 10.0.0.alpha0 hasta 10.0.0.beta2 y 11.0.0.alpha0 hasta 11.0.0.beta2, si la inflación del cuerpo de la petición GZIP está habilitada y solicita de diferentes clientes se multiplexan en una sola conexión, y si un atacante puede enviar una petición con un cuerpo que es recibido por completo pero no consumido por la aplicación, entonces una petición posterior en la misma conexión verá ese cuerpo antepuesto a su cuerpo. El atacante no verá ningún dato, pero puede inyectar datos en el cuerpo de la petición posterior • https://bugs.eclipse.org/bugs/show_bug.cgi?id=568892 https://github.com/eclipse/jetty.project/security/advisories/GHSA-86wm-rrjm-8wh8 https://lists.apache.org/thread.html/r00858fe27ee35ac8fa0e1549d67e0efb789d63b791b5300390bd8480%40%3Cjira.kafka.apache.org%3E https://lists.apache.org/thread.html/r01806ad8c9cb0590584baf5b1a60237ad92e4ad5bba082ca04d98179%40%3Creviews.spark.apache.org%3E https://lists.apache.org/thread.html/r05b7ffde2b8c180709e14bc9ca036407bea3ed9f09b32c4705d23a4a%40%3Cjira.kafka.apache.org%3E https://lists.apache.org/thread.html/r078c120 • CWE-226: Sensitive Information in Resource Not Removed Before Reuse •