CVE-2020-8908: Google Guava Information Disclosure Bug

CVE-2020-8908 Overview

A temporary directory creation vulnerability exists in Google Guava, a widely-used Java library. The vulnerability affects the com.google.common.io.Files.createTempDir() API method, which creates temporary directories with insecure default permissions on Unix-like systems. By default, these directories are created as world-readable (mode 0755), allowing any local user with access to the system to potentially read data stored in the temporary directory.

Critical Impact

Local attackers with system access can read sensitive data from temporary directories created by applications using the vulnerable Guava API, potentially leading to information disclosure of sensitive application data, credentials, or session information.

Affected Products

• Google Guava (all versions prior to deprecation in 30.0)
• Oracle WebLogic Server 14.1.1.0.0
• Oracle Data Integrator 12.2.1.3.0 and 12.2.1.4.0
• Oracle PeopleSoft Enterprise PeopleTools 8.57, 8.58, 8.59
• Oracle Primavera Unifier 18.8, 19.12, 20.12, 21.12
• Oracle Communications Cloud Native Core Network Repository Function 1.14.0
• Quarkus (multiple versions)
• NetApp Active IQ Unified Manager (Linux, VMware vSphere, Windows)

Discovery Timeline

• December 10, 2020 - CVE-2020-8908 published to NVD
• February 23, 2026 - Last updated in NVD database

Technical Details for CVE-2020-8908

Vulnerability Analysis

This vulnerability stems from insecure default file permissions when creating temporary directories through Guava's Files.createTempDir() method. On Unix-like operating systems, the method creates directories with world-readable permissions, deviating from secure practices that would restrict access to the creating user only.

The issue is particularly concerning in multi-user environments or shared hosting scenarios where multiple users or processes have access to the system's temporary directory (typically /tmp or the path specified by java.io.tmpdir). Any application storing sensitive data in these temporary directories could inadvertently expose that information to other users on the system.

The vulnerability requires local access to exploit, meaning an attacker must already have some level of access to the target system. However, in shared environments or systems with multiple users, this represents a realistic attack scenario.

Root Cause

The root cause is the use of File.createTempFile() internally, which inherits the default umask settings of the system rather than explicitly setting restrictive permissions (mode 0700). The Java API does not provide a straightforward mechanism to atomically create a directory with specific permissions, leading to this insecure default behavior. The method relies on system defaults which typically result in world-readable directories on Unix-like systems.

Attack Vector

The attack requires local access to the target machine. An attacker with a valid user account on the system can monitor the temporary directory for newly created Guava temporary directories. Once identified, the attacker can read the contents of files written to these directories by the vulnerable application. This could include:

• Application configuration files
• Session data or tokens
• Cached credentials
• Temporary processing data containing sensitive information

The following patch was applied to deprecate the vulnerable method and warn developers about the security implications:

    * be exploited to create security vulnerabilities, especially when executable files are to be
    * written into the directory.
    *
+   * <p>Depending on the environmment that this code is run in, the system temporary directory (and
+   * thus the directory this method creates) may be more visible that a program would like - files
+   * written to this directory may be read or overwritten by hostile programs running on the same
+   * machine.
+   *
    * <p>This method assumes that the temporary volume is writable, has free inodes and free blocks,
    * and that it will not be called thousands of times per second.
    *

Source: GitHub Commit

Detection Methods for CVE-2020-8908

Indicators of Compromise

• Presence of world-readable temporary directories in /tmp or the system's configured temporary directory with Guava-style naming patterns
• Unexpected read access to temporary directories by non-owner users or processes
• Log entries indicating access to application temporary files by unauthorized user accounts
• Discovery of Guava library versions prior to 30.0 in application dependencies

Detection Strategies

• Audit application dependencies using software composition analysis (SCA) tools to identify vulnerable Guava versions
• Monitor file system permissions on temporary directories for world-readable configurations
• Implement file integrity monitoring on temporary directories to detect unauthorized access
• Review application source code for usage of com.google.common.io.Files.createTempDir() method calls

Monitoring Recommendations

• Enable audit logging for file access in temporary directories on multi-user systems
• Configure SentinelOne agents to monitor for suspicious file access patterns in temporary storage locations
• Implement dependency scanning in CI/CD pipelines to detect vulnerable library versions before deployment
• Use runtime application self-protection (RASP) solutions to monitor temporary file operations

How to Mitigate CVE-2020-8908

Immediate Actions Required

• Identify all applications using Google Guava and audit usage of Files.createTempDir() method
• Upgrade to Guava version 30.0 or later where the method is marked as deprecated with security warnings
• Migrate to secure alternatives such as java.nio.file.Files.createTempDirectory() which sets permissions to 0700
• For Android applications, use Android-provided alternatives such as context.getCacheDir()

Patch Information

Google has marked the Files.createTempDir() method as @Deprecated in Guava version 30.0 and later. The deprecation notice explicitly warns developers about the security implications and recommends migration to safer alternatives. For detailed patch information, refer to the GitHub Commit and the GitHub Issue Discussion.

Oracle has addressed this vulnerability in multiple Critical Patch Updates (CPUs) for affected products. Refer to Oracle CPU April 2021, Oracle CPU July 2021, Oracle CPU October 2021, and Oracle CPU April 2022 for product-specific patches.

Workarounds

• Configure the java.io.tmpdir system property to point to a directory with appropriately restrictive permissions (accessible only by the application user)
• Implement explicit permission setting immediately after directory creation using java.nio.file.Files.setPosixFilePermissions()
• Use java.nio.file.Files.createTempDirectory() which creates directories with mode 0700 by default
• For Android applications, migrate to context.getCacheDir() or context.getFilesDir() which provide application-private storage

# Configuration example - Set restrictive tmpdir for Java applications
# Create a private temporary directory
mkdir -p /opt/app/tmp
chmod 700 /opt/app/tmp
chown appuser:appgroup /opt/app/tmp

# Launch Java application with custom tmpdir
java -Djava.io.tmpdir=/opt/app/tmp -jar application.jar