Skip to content

← Public intelligence

Maven package

com.google.guava:guava

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.2MavenAmendedPublished

    Google Guava: CompactHashMap/CompactHashSet/MapMakerInternalMap deserialization triggers uncontrolled memory allocation

    CVE-2026-102554 · GHSA-xxph-c9ww-hj94

    Affected
    • Maven com.google.guava:guava >= 4.0, < 33.7.2
    Fixed in
    33.7.2· Vendor fix available
    Issue
    CompactHashMap/CompactHashSet/MapMakerInternalMap native deserialization triggers uncontrolled memory allocation Summary `CompactHashMap`, `CompactHashSet`, and `MapMakerInternalMap` implement `readObject(ObjectInputStream)` by reading an attacker-controlled `elementCount` or `initialCapacity` from the stream. On the very first insertion during or after deserialization (for the `CompactHash*` collections, inside `allocArrays()`) or immediately during deserialization (for `MapMakerInternalMap`), the implementation eagerly allocates arrays sized to that full, unvalidated value (up to `CompactHashing.MAX_SIZE` = 2^30-1, ~1.07 billion, for example) before the rest of the stream's actual content has been consumed. A 72-byte malicious serialized stream containing a single tiny element can force a multi-gigabyte allocation and crash a JVM with `OutOfMemoryError`, dynamically confirmed against the current release. Details `CompactHashMap.readObject()`…

    Recommended action: Upgrade to 33.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Medium, CVSS 5.5MavenPublished

    Guava vulnerable to insecure use of temporary directory

    CVE-2023-2976 · GHSA-7g45-4rm6-3mm3

    Affected
    • Maven com.google.guava:guava >= 1.0, < 32.0.0-android
    Fixed in
    32.0.0-android· Vendor fix available
    Issue
    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, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

    Recommended action: Upgrade to 32.0.0-android (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. Low, CVSS 3.3MavenPublished

    Information Disclosure in Guava

    CVE-2020-8908 · GHSA-5mg8-w23w-74h3

    Affected
    • Maven com.google.guava:guava < 32.0.0-android
    Fixed in
    32.0.0-android· Vendor fix available
    Issue
    A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava com.google.common.io.Files.createTempDir(). The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method.

    Recommended action: Upgrade to 32.0.0-android (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →