CVE-2020-8908

What it actually does

CVE-2020-8908 is a local information disclosure weakness in Google Guava's com.google.common.io.Files.createTempDir() API. On Unix-like systems, temporary directories created by this API can be world-readable by default, meaning another local user or process on the same machine may be able to list or read files placed in that directory. The flaw does not provide remote code execution, privilege escalation, or direct integrity impact by itself, but it can expose sensitive temporary data such as tokens, intermediate files, uploaded content, serialized objects, logs, or application-generated secrets if an affected application writes them into the insecure directory. The vulnerable API is deprecated in Guava 30.0 and later; safer alternatives include java.nio.file.Files.createTempDirectory(), which creates directories with restrictive permissions, or platform-specific secure cache APIs on Android.

Why it matters to the business

The primary business risk is accidental exposure of sensitive application data to another user or compromised process on the same system. This can matter most on shared servers, build systems, CI/CD runners, multi-user Unix hosts, developer workstations, container hosts with weak isolation, or systems where untrusted local users can execute code. The CVSS and EPSS values indicate relatively low widespread exploitation likelihood compared with remotely exploitable vulnerabilities, and it is not listed in CISA KEV, but exploit code or exploitation techniques are available and the issue has been public for years, so affected legacy dependencies should still be remediated during dependency hygiene and hardening efforts.

How an attack unfolds

An attacker first needs local access to the same operating system instance where an affected Java application runs, either through a legitimate low-privileged account, a compromised service account, a malicious local process, or access to a shared build or runtime host. The attacker identifies that the application uses Guava's Files.createTempDir() and creates temporary directories under a shared location such as /tmp. Because the created directory may be world-readable on Unix-like systems, the attacker monitors temporary directory creation, lists accessible directories, and attempts to read files written there before the application deletes them. If the application stores sensitive data in those temporary files, the attacker can collect credentials, tokens, user content, configuration fragments, or other confidential data. Exploitation is opportunistic and timing-dependent, but straightforward once local access and knowledge of the temporary file location exist.

How to fix it

Upgrade or refactor affected code so it no longer uses com.google.common.io.Files.createTempDir(). For Java 7 and later, migrate to java.nio.file.Files.createTempDirectory(), which creates directories with restrictive permissions such as owner-only access on supported platforms. For Android, use platform-provided APIs such as context.getCacheDir(). If immediate code changes are not possible, configure the Java runtime's java.io.tmpdir property to point to a directory with appropriately restrictive permissions, ensure the parent temporary directory is not shared with untrusted users, and explicitly set permissions to 0700 on created directories before writing sensitive data. Use fixed versions where applicable: quarkusio/quarkus fixed in commit 60a549cadba9f9e10583b4348b5102e8b4087aa7, google/guava fixed in commit fec0dbc4634006a6162cfd4d0d09c962073ddf40, and Debian 9 pidgin fixed in 2.12.0-1+deb9u1. Also ensure transitive dependencies do not reintroduce vulnerable Guava usage.

How to confirm the fix worked

Confirm remediation through both dependency and behavior checks. Use software composition analysis, build manifests, Maven or Gradle dependency trees, SBOMs, and source searches to identify any remaining use of com.google.common.io.Files.createTempDir(). Verify that Guava versions in use are updated and that application code has migrated to java.nio.file.Files.createTempDirectory() or another secure platform API. On Unix-like systems, run the application in a test environment and inspect created temporary directories with ls -ld to confirm permissions are owner-only, typically drwx------ or mode 0700. Validate that java.io.tmpdir, if customized, points to a directory not readable by untrusted users. For packaged products, confirm installed package versions match or exceed the fixed versions provided by the vendor or distribution.

Typical attack path

1. Obtain local shell, process execution, or another foothold on the same Unix-like host as the affected Java application.
2. Identify that the target application includes a vulnerable Guava version or calls com.google.common.io.Files.createTempDir().
3. Monitor shared temporary locations such as /tmp for newly created application temporary directories.
4. Check directory permissions and identify directories that are world-readable or listable.
5. Read or copy sensitive files written by the application into the insecure temporary directory before cleanup occurs.
6. Use the disclosed data for follow-on access, credential theft, session hijacking, or reconnaissance, depending on the data exposed.

How to detect it

There are no universal network indicators or reliable log strings that prove exploitation, because the issue is a local file-permission exposure and successful access may look like ordinary file reads. To assess possible prior exploitation, review host audit logs, EDR telemetry, Linux auditd records, shell history, process execution logs, and file access monitoring for low-privileged users or unexpected processes listing or reading application-created temporary directories. Focus on shared Unix-like systems and time windows when affected applications created temporary files. Look for commands such as ls, find, cat, cp, grep, tar, or rsync accessing application temporary directories under /tmp or the configured java.io.tmpdir path. If auditd or EDR file telemetry is available, correlate directory creation events by Java processes with subsequent read or copy events by unrelated users or processes. Also inspect application logs for temporary file paths, then check whether those paths had world-readable permissions at creation time. Source and dependency scanning can identify exposure, but confirming exploitation generally requires file access telemetry or forensic artifacts showing unauthorized reads.

• com.google.common.io.Files.createTempDir(
• com.google.common.io.Files.createTempDir()
• java.io.tmpdir
• /tmp/
• drwxr-xr-x
• drwxrwxr-x
• Files.createTempDir
• java.nio.file.Files.createTempDirectory

What your security team should do

• Prioritize remediation on shared Unix-like systems, CI/CD runners, developer workstations, bastion hosts, and any application servers where untrusted or lower-privileged local users can execute code.
• Search source code and dependencies for com.google.common.io.Files.createTempDir() and replace it with java.nio.file.Files.createTempDirectory() or secure platform-specific APIs.
• Use SCA tooling and SBOM review to identify applications that include vulnerable Guava versions or downstream products known to have been affected.
• Harden temporary directory configuration by setting java.io.tmpdir to an application-specific directory with 0700 permissions where practical.
• Avoid writing secrets, credentials, private keys, session tokens, or sensitive user data to temporary directories unless permissions are explicitly controlled and cleanup is reliable.
• Add regression tests that assert secure permissions on application-created temporary directories.
• Review local access controls on systems running affected applications, because exploitation requires local access or execution on the same host.
• Treat any evidence of local reads from application temporary directories as potential data exposure and investigate what data was present during the access window.