Safeguard
Application Security•

CWE-378 Temporary File With Insecure Permissions: Causes and Fixes

A temp file readable or writable by other users leaks data and gives attackers a trusted input. CWE-378 explained, with the Java createTempFile case and fixes.

Safeguard Security Team
3 min read

Opening a temporary file without the right controls leaves the file, its contents and anything that depends on it open to attack. That is CWE-378, Creation of Temporary File With Insecure Permissions. The focus is the file itself: who can read it, who can write it.

It applies to any language. MITRE notes that older C temp file functions are especially susceptible, while many contemporary languages ship functions that handle the problem properly if you use them.

How it happens

The usual cause is relying on the default. A function creates the file with permissions that suit a single-user machine and nothing else. On a shared host, other local accounts can then open it.

The record gives a clear example: CVE-2022-24823. A network application framework used the Java createTempFile() function, which creates a file readable by other local users of the system.

// Vulnerable on shared Unix hosts: default mode is readable by others
File f = File.createTempFile("upload-", ".tmp");
Files.write(f.toPath(), uploadedBytes);

What an attacker gains

MITRE lists three consequences:

  • Confidentiality. If the attacker can read the file, sensitive information in it may be revealed.
  • Authorization. If the attacker can write to the file, it might be moved somewhere the attacker could not otherwise reach, giving selective access-control privileges.
  • Integrity. The file becomes an extra input channel that the program trusts as non-malicious. It may allow arbitrary changes to data structures, user information, or even process ownership.

How to find it

MITRE says automated static analysis (SAST) can find some instances by analyzing source code. Add a manual check: run your tests, then list the permissions of every file your app left in the temp directory. Anything group or world readable that holds real data is a finding. Dependencies can carry the bug too, so scan them as well with the free tool at gold.safeguard.sh/scan.

How to fix it

MITRE's mitigations are short and practical.

  1. Use proper file permissions, ideally through a safe temp file function. Temporary files should be readable and writable only by the process that owns them.
  2. Randomize temporary file names, again by using a safe temp file function, so files are not created in predictable places.
  3. Prefer languages and libraries whose temp file functions already do this, and avoid the older C functions.
FileAttribute<Set<PosixFilePermission>> ownerOnly =
    PosixFilePermissions.asFileAttribute(PosixFilePermissions.fromString("rw-------"));
Path f = Files.createTempFile("upload-", ".tmp", ownerOnly);
import tempfile
with tempfile.TemporaryFile() as f:   # owner-only, removed on close
    f.write(uploaded_bytes)

Quick check

What is the safest way to get owner-only permissions? Use the platform's safe temp file function and, where it is not the default, set owner-only permissions at creation time. Changing permissions after creation leaves a window where the file is open.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.