Google Guava CVE-2026-102554

Exploitation requires that the target application performs Java native deserialization (ObjectInputStream.readObject) on attacker-influenced input, and that the deserialized graph includes a Guava CompactHashMap, CompactHashSet, or MapMakerInternalMap instance. The specific trigger is a forged size/element-count field in the serialization stream, which Guava's readObject uses to eagerly size a backing array without throttling. LIMITING FACTORS: the flaw is unreachable in applications that never deserialize untrusted serialized objects (a widely discouraged pattern), so despite PR:N/UI:N the CVSS 4.0 vector marks AT:P - a non-default application behavior is the gating prerequisite. No authentication or user interaction is required by Guava itself, but any authentication/authorization in front of the deserializing endpoint further limits reach. Impact is limited to availability; the oversized allocation does not yield code execution or data disclosure.

This is a genuine but conditional availability-only risk. The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, score 8.2) encodes network, unauthenticated reach with low complexity but an explicit Attack Requirement (AT:P) - that requirement is the crux: exploitation is only possible if the consuming application deserializes untrusted Java serialized data containing Guava's CompactHashMap, CompactHashSet, or MapMakerInternalMap. There is no confidentiality or integrity impact (VC:N/VI:N) - only availability via OutOfMemoryError (VA:H). No EPSS score, CISA KEV listing, or POC flag was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the elevated score is driven by broad network reach plus Guava's enormous install base rather than by observed in-the-wild activity. One nuance to verify: the fix commit (b931fe9) ships regression tests that demonstrate triggering the condition by forging the size field, which lowers the practical difficulty of weaponization even though no standalone exploit is catalogued. Net: prioritize for patching anywhere the application accepts and deserializes untrusted serialized streams, but down-rank for applications that never deserialize attacker-controlled data, where the vulnerable code path is unreachable.

An application exposes an endpoint or message consumer that deserializes Java serialized objects from an untrusted source and transitively uses affected Guava collections. An attacker submits a crafted serialization stream whose encoded element-count/size field is set to a very large value (e.g., Integer.MAX_VALUE), causing Guava's readObject to eagerly allocate a huge backing array and exhaust the JVM heap, crashing the service with OutOfMemoryError. No public standalone exploit is catalogued, but the fix commit includes a demonstrative regression test showing exactly how the oversized size field triggers the fault.