CWE-377 Insecure Temporary File: How It Happens and How to Fix It

Almost every program writes a temporary file at some point: an upload buffer, a cache, an unpacked archive, a report in progress. Those files often hold data you would never put in a public directory, and they sit in a directory that other users on the same machine can see. CWE-377 is the class for creating and using insecure temporary files so that application and system data become vulnerable to attack.

It hits any language and any platform where more than one user, container or process shares a temp directory. That includes CI runners, shared build hosts and multi-tenant servers.

How it happens

MITRE keeps this entry broad, and its child weaknesses name the specifics. The common patterns:

• The file is created with default permissions that let other local users read it.
• The file name is predictable, so another user can create or replace it first.
• The file is written to a shared directory without any thought to who else can list it.
• Old C temp file functions that generate a name but do not create the file atomically.

A real example from the record: CVE-2022-41954. A library used the Java File.createTempFile() method, which creates a file with -rw-r--r-- default permissions on Unix-like operating systems. Anyone on the box could read it.

Here is the Java pattern:

// Vulnerable on Unix: file is world readable by default
File tmp = File.createTempFile("export-", ".csv");
Files.writeString(tmp.toPath(), sensitiveReport);

And a Python equivalent that builds a predictable name:

# Vulnerable: predictable path in a shared directory
path = "/tmp/report_" + str(user_id) + ".csv"
open(path, "w").write(report)

What an attacker gains

MITRE lists confidentiality and integrity impact: attackers can read files or directories, and modify files or directories. Read access leaks whatever you wrote. Write access to a predictable path lets a local attacker plant a file or link that your program then reads or overwrites.

How to find it

MITRE notes that automated static analysis (SAST) can find some instances of this weakness by analyzing source code. A few simple checks add coverage:

• Grep for createTempFile, tmpnam, tempnam, mktemp and any code that concatenates /tmp/ with a name.
• Check the permissions of files your app leaves behind during a test run.
• Look at third party libraries too. The CVE above lived in a library, not in application code, so a dependency scan matters as much as a code scan. You can run the free in-browser scan at gold.safeguard.sh/scan. No login, the file stays on your machine, and it handles up to 100 dependencies.

How to fix it

The principle is the same everywhere: let the platform create the file atomically, with owner-only permissions, in a directory you control.

In Java, use the NIO API, which on POSIX systems creates the file with owner-only permissions:

Path tmp = Files.createTempFile("export-", ".csv");
// or set permissions explicitly
FileAttribute<Set<PosixFilePermission>> attr =
    PosixFilePermissions.asFileAttribute(PosixFilePermissions.fromString("rw-------"));
Path safe = Files.createTempFile("export-", ".csv", attr);

In Python, use tempfile:

import tempfile
with tempfile.NamedTemporaryFile("w", suffix=".csv") as f:
    f.write(report)

Then add the habits that apply everywhere:

• Never build temp paths by hand.
• Prefer a per-user or per-process private directory over a shared one.
• Delete the file as soon as you are done.
• Keep sensitive content off disk entirely when memory will do.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE CWE-377
• Safeguard Gold entry for CWE-377