CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 0CVE-2023-2976 – Use of temporary directory for file creation in `FileBackedOutputStream` in Guava
https://notcve.org/view.php?id=CVE-2023-2976
Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. A flaw was found in Guava. The methodology for temporary directories and files can allow other local users or apps with accordant permissions to access the temp files, possibly leading to information exposure or tampering in the files created in the directory. • https://github.com/google/guava/issues/2575 https://security.netapp.com/advisory/ntap-20230818-0008 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01006.html https://access.redhat.com/security/cve/CVE-2023-2976 https://bugzilla.redhat.com/show_bug.cgi?id=2215229 • CWE-552: Files or Directories Accessible to External Parties •
CVSS: 3.3EPSS: 0%CPEs: 23EXPL: 1CVE-2020-8908 – Temp directory permission issue in Guava
https://notcve.org/view.php?id=CVE-2020-8908
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: 1%CPEs: 42EXPL: 0CVE-2018-10237 – guava: Unbounded memory allocation in AtomicDoubleArray and CompoundOrdering classes allow remote attackers to cause a denial of service
https://notcve.org/view.php?id=CVE-2018-10237
Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. Asignación de memoria sin restringir en Google Guava 11.0 hasta las versiones 24.x anteriores a la 24.1.1 permite que los atacantes remotos realicen ataques de denegación de servicio (DoS) contra servidores que dependen de esta librería y que deserialicen datos proporcionados por dichos atacantes debido a que la clase AtomicDoubleArray (cuando se serializa con serialización Java) y la clase CompoundOrdering (cuando se serializa con serialización GWT) realiza una asignación sin comprobar adecuadamente lo que ha enviado un cliente y si el tamaño de los datos es razonable. A vulnerability was found in Guava where the AtomicDoubleArray and CompoundOrdering classes were found to allocate memory based on size fields sent by the client without validation. A crafted message could cause the server to consume all available memory or crash leading to a denial of service. • http://www.securitytracker.com/id/1041707 https://access.redhat.com/errata/RHSA-2018:2423 https://access.redhat.com/errata/RHSA-2018:2424 https://access.redhat.com/errata/RHSA-2018:2425 https://access.redhat.com/errata/RHSA-2018:2428 https://access.redhat.com/errata/RHSA-2018:2598 https://access.redhat.com/errata/RHSA-2018:2643 https://access.redhat.com/errata/RHSA-2018:2740 https://access.redhat.com/errata/RHSA-2018:2741 https://access.redhat.com/errata/RHSA-2018:274 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-770: Allocation of Resources Without Limits or Throttling •