CVE-2023-2976

What it actually does

In affected Google Guava versions 1.0 through 31.1, FileBackedOutputStream creates spill-to-disk temporary files in Java's default temporary directory, commonly /tmp on Unix-like systems. On shared Unix systems or affected Android versions, other local users or apps with access to that directory may be able to discover and read those temporary files while they exist, exposing any data the application buffered through FileBackedOutputStream. The flaw is a local information disclosure issue: it does not directly provide remote code execution, privilege escalation, or data modification, but it can expose highly sensitive contents depending on what the application writes to the stream.

Why it matters to the business

Applications that use vulnerable Guava versions may unintentionally expose sensitive data such as uploaded files, API responses, documents, tokens, customer records, or intermediate processing data to other local users or applications on the same machine. The operational risk is highest on multi-tenant servers, shared build systems, developer workstations, batch-processing hosts, and Android environments where untrusted local apps or users may coexist. EPSS is low and the issue is not in CISA KEV, so broad internet-scale exploitation is unlikely; however, Guava is a common transitive dependency, making inventory and dependency remediation important across Java estates.

How an attack unfolds

An attacker first needs local access to the same Unix-like host or affected Android environment as an application using Guava FileBackedOutputStream. The attacker identifies that the target process uses Guava 1.0 through 31.1 and writes data large enough, or in a configured way, to spill from memory to disk. The attacker monitors the Java default temporary directory, typically /tmp, for files with the FileBackedOutputStream temporary-file naming pattern. When the application creates one of these files, the attacker attempts to read or copy it before it is deleted. Successful exploitation yields the contents written by the vulnerable application to the temporary file. The provided threat-actor labels appear to reference unrelated vulnerabilities rather than confirmed actors for this issue; there is no strong public evidence of widespread exploitation or ransomware use.

How to fix it

Upgrade Google Guava to a fixed release. The vulnerability is fixed in Guava 32.0.0, but Guava 32.0.1 or later is recommended because 32.0.0 introduced Windows functionality regressions. For source-based tracking, google/guava is fixed at commit 6b1f97ced922d48f071153ad9e631d06383033a4. Review direct and transitive dependencies in Maven, Gradle, Bazel, SBT, and vendored Java artifacts to ensure no runtime path still resolves to Guava 31.1 or earlier. If immediate upgrade is not possible, reduce exposure by running affected workloads on single-tenant hosts, restricting local shell or app co-tenancy, setting Java's temporary directory to a private directory with mode 0700, hardening /tmp mount options where appropriate, and avoiding use of FileBackedOutputStream for sensitive data until patched. Where the affected package inventory also includes Ubuntu kernel packages, apply the listed vendor-fixed kernel packages for the relevant releases, including Ubuntu 14.04 linux 3.13.0-65.105, linux-aws 4.4.0-1002.2, linux-lts-xenial 4.4.0-13.29~14.04.1, and Ubuntu 16.04 linux 4.2.0-16.19 or the corresponding listed flavor-specific fixed versions.

How to confirm the fix worked

Confirm that applications resolve Guava 32.0.1 or later at runtime, not merely at build time. Use dependency tooling such as mvn dependency:tree, gradle dependencies, sbt dependencyTree, Bazel query, software composition analysis, and jar inspection to locate guava-*.jar files. Inspect packaged applications, fat JARs, container images, application servers, and plugin directories for guava versions 31.1 or older. Validate that Java processes do not create FileBackedOutputStream temporary files in shared directories by running functional tests under file-system monitoring and confirming that any temporary spill files are created only in private directories with owner-only permissions. On Linux, verify private temp-directory permissions with stat and confirm relevant packages are updated with the operating system package manager where vendor packages are in scope.

Typical attack path

1. Obtain local user, container, shell, or app-level access on the same Unix-like or affected Android system as the vulnerable Java application.
2. Determine or infer that the application uses a vulnerable Guava version and the FileBackedOutputStream class.
3. Monitor the Java default temporary directory, commonly /tmp, for temporary files whose names begin with FileBackedOutputStream.
4. Read, copy, or continuously tail accessible temporary files while the application is processing data.
5. Extract sensitive contents from the captured temporary files before the application deletes them.

How to detect it

Historical exploitation is difficult to prove unless file access auditing was already enabled, because the temporary files may be deleted quickly and ordinary application logs usually do not record local reads. Review Linux auditd, eBPF/Falco telemetry, EDR file-event logs, shell history, process accounting, and filesystem monitoring for reads or copies of FileBackedOutputStream temporary files by users or processes other than the Java application owner. Search for suspicious commands such as cat, cp, tail, less, grep, strings, tar, or exfiltration tools accessing /tmp/FileBackedOutputStream* files. Review /tmp and any configured java.io.tmpdir locations for residual FileBackedOutputStream files, unexpected permissions, or copied archives. Correlate file-read events with application processing windows that may have handled sensitive data. If audit logs show another user or untrusted process opening these files, scope the incident as possible data disclosure.

• /tmp/FileBackedOutputStream
• /var/tmp/FileBackedOutputStream
• FileBackedOutputStream*.tmp
• guava-31.1-jre.jar
• guava-31.1-android.jar
• guava-30.1.1-jre.jar
• guava-30.1-jre.jar
• guava-29.0-jre.jar
• guava-28.2-jre.jar
• guava-27.1-jre.jar
• guava-26.0-jre.jar
• guava-25.1-jre.jar
• guava-24.1.1-jre.jar
• guava-23.6-jre.jar
• guava-22.0.jar
• guava-21.0.jar
• java.io.tmpdir=/tmp
• openat*FileBackedOutputStream
• cat /tmp/FileBackedOutputStream
• cp /tmp/FileBackedOutputStream
• tail -f /tmp/FileBackedOutputStream
• less /tmp/FileBackedOutputStream
• strings /tmp/FileBackedOutputStream

What your security team should do

• Prioritize dependency upgrades for internet-facing, multi-tenant, shared-host, CI/CD, batch-processing, and document-processing Java applications that use Guava.
• Standardize on Guava 32.0.1 or later and block Guava 31.1 or older in dependency policy gates and software composition analysis tooling.
• Search container images, fat JARs, application server libraries, plugins, and build caches for vulnerable guava-*.jar files because Guava is frequently included transitively.
• For systems that cannot be upgraded immediately, configure Java temporary directories to private 0700 paths and remove untrusted local users or applications from affected hosts.
• Enable or review file access auditing for shared temporary directories on high-risk systems to identify unexpected reads of FileBackedOutputStream temporary files.
• Treat any confirmed unauthorized access to these temporary files as potential sensitive-data exposure and follow data-handling, legal, and incident-response procedures.