WaratekVRT Sign in

Guava CVEs

4 CVEs, 2 protected by Waratek

Reset
More filters (1)
Columns
Product guava✕
Overview 4 matches · 2 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
4matches 2protected50.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 2 50.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 2 50.0%
Critical 0 0.0% High 2 50.0% Medium 1 25.0% Low 1 25.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 2 50.0% partly blocked 0 0.0% not blocked 2 50.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 25.0% Forecast only 0 0.0% No public exploit 3 75.0%
split by peak 1 / year
No exploit published: 2Protected by Waratek: 2 Low: 1Medium: 1High: 2 not blocked: 2blocked by ARMR today: 2 No public exploit: 3Proof of concept only: 1
20181 Protected by Waratek1 Medium1 blocked by ARMR today1 No public exploit1 20190 20201 No exploit published1 Low1 not blocked1 No public exploit1 20210 20220 20231 No exploit published1 High1 not blocked1 No public exploit1 20240 20250 20261 Protected by Waratek1 High1 blocked by ARMR today1 Proof of concept only1
201820192020202120222023202420252026
4 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-102554 High 2026-10-09 Protected by Waratek Proof of concept only Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams.
CVE-2023-2976 High 2023-06-14 No exploit published No public exploit 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.
CVE-2020-8908 Low 2020-12-10 No exploit published No public exploit 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.
CVE-2018-10237 Medium 2018-04-26 Protected by Waratek No public exploit 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.