Temporary files are often created with predictable names, world-readable permissions, or in shared directories where other users or processes can access or…
Temporary files are often created with predictable names, world-readable permissions, or in shared directories where other users or processes can access or modify them. This weakness allows an attacker to read sensitive data from the temp file, replace it with malicious content before the application uses it, or exploit a race condition between file creation and permission-setting. Even on single-user systems, temporary files can be exploited by malware or privilege-escalation attacks.
02How It Happens
Applications frequently need scratch space for intermediate data — caches, session tokens, uploaded file processing, or log buffers. Developers often create these files using simple string concatenation with predictable names (e.g., /tmp/app_user_123.txt) or in world-writable directories without restricting access. The vulnerability emerges when the file is created with default permissions (often 0644 or world-readable), or when there is a time gap between file creation and permission-setting. An attacker on the same system can predict the filename, read or overwrite it before the application does, or create a symlink at that path to redirect writes to a sensitive file.
03Real-World Impact
An attacker can steal session tokens, API keys, or personally identifiable information stored in temporary files. By replacing a temp file with malicious content before the application reads it, an attacker can inject commands, corrupt data, or trigger unintended behavior. On multi-user systems, privilege-escalation attacks often exploit insecure temp files to write to files owned by other users or to execute code with elevated privileges. Even on single-user systems, malware can abuse predictable temp file locations to persist or exfiltrate data.
04Vulnerable & Fixed Patterns
Vulnerable pattern
import tempfile
import os
# Vulnerable: predictable filename in shared temp directory
temp_filename = f"/tmp/app_session_{os.getuid()}.txt"
with open(temp_filename, "w") as f:
f.write(session_token)
# File is world-readable by default; attacker can read it
# or create a symlink at that path before this code runs
Why it's vulnerable: The filename is predictable and the file is created in a world-writable directory with default permissions, allowing other users or processes to read, replace, or symlink it.
Fixed pattern
import tempfile
# Fixed: use tempfile.NamedTemporaryFile for secure creation
with tempfile.NamedTemporaryFile(mode='w', delete=False, dir='/tmp') as f:
temp_filename = f.name
f.write(session_token)
# File is created with mode 0600 (readable/writable by owner only)
# Filename is cryptographically random and unique
Vulnerable pattern
<?php
// Vulnerable: predictable filename in /tmp
$temp_file = "/tmp/upload_" . $_SESSION['user_id'] . ".tmp";
$_FILES['document']['tmp_name'] = $temp_file;
move_uploaded_file($_FILES['document']['tmp_name'], $temp_file);
// Attacker can predict the filename and replace it
// or read sensitive data before the application processes it
?>
Why it's vulnerable: The filename is constructed from a predictable user ID and stored in a world-writable directory. An attacker can create a symlink or file at that path before the upload completes.
Fixed pattern
<?php
// Fixed: use sys_get_temp_dir() and uniqid() or random bytes
$temp_file = sys_get_temp_dir() . DIRECTORY_SEPARATOR .
'upload_' . bin2hex(random_bytes(16)) . '.tmp';
chmod($temp_file, 0600); // Restrict to owner only
move_uploaded_file($_FILES['document']['tmp_name'], $temp_file);
// Filename is cryptographically random; permissions are restrictive
?>
05Prevention Checklist
Use language-provided secure temp file functions (tempfile.NamedTemporaryFile in Python, tempnam() or sys_get_temp_dir() in PHP) that generate cryptographically random names and set restrictive permissions automatically.
Never construct temp filenames using predictable data (user IDs, timestamps, sequential numbers). Use cryptographic randomness (random_bytes(), secrets module, or OS-level random sources).
Set file permissions to 0600 (owner read/write only) immediately after creation; do not rely on default umask.
Avoid storing sensitive data (tokens, keys, PII) in temp files. If unavoidable, encrypt the contents and delete the file as soon as it is no longer needed.
Use a dedicated, application-controlled temp directory with restrictive permissions (0700) rather than system-wide /tmp or %TEMP% if possible.
On multi-user systems, verify that the temp directory itself is not world-writable and that the application runs with minimal privileges.
06Signs You May Already Be Affected
Check for unexpected files in system temp directories (/tmp, /var/tmp, %TEMP%) with names matching your application's pattern. Review application logs for errors related to temp file creation or permission denial. On multi-user systems, verify that temp files created by your application are not readable by other users (use ls -la /tmp | grep <app_name>). If you find world-readable temp files or symlinks pointing to sensitive system files, investigate whether an attacker has exploited this weakness.
