This weakness occurs when an application creates temporary files in a directory that is world-readable or world-writable, allowing other users on the same…
This weakness occurs when an application creates temporary files in a directory that is world-readable or world-writable, allowing other users on the same system to read sensitive data or replace the file with malicious content. On shared hosting, multi-user systems, or containers, this can lead to information disclosure or privilege escalation. The root cause is usually a combination of insecure file creation and inadequate directory permissions.
When an application needs temporary storage—for caching, processing uploads, or staging data—it often creates files in system-wide temporary directories like /tmp or %TEMP%. If the application does not explicitly set restrictive permissions on the file at creation time, or if the parent directory itself is world-writable, other users or processes can access or modify that file. The problem is compounded when the temporary file contains sensitive information (credentials, session tokens, personal data) or when the application later trusts the file's contents without verifying its integrity.
An attacker with local system access can read temporary files containing passwords, API keys, or user data. On shared hosting platforms, one customer's application could leak another customer's secrets. An attacker could also replace a temporary file before the application reads it, causing the application to process malicious data—potentially leading to code execution, data corruption, or privilege escalation if the application runs with elevated permissions.
import tempfile
import os
# Vulnerable: creates file in /tmp with default permissions
temp_file = tempfile.NamedTemporaryFile(mode='w', delete=False)
temp_file.write(user_session_token)
temp_file.close()
# File is readable by any user on the system
process_data(temp_file.name)
os.unlink(temp_file.name)Why it's vulnerable:
NamedTemporaryFile without explicit mode restrictions creates a file readable by other users. The session token is exposed to any process running on the system.
import tempfile
import os
# Fixed: create file with restrictive permissions (0o600)
fd, temp_path = tempfile.mkstemp(mode=0o600)
try:
with os.fdopen(fd, 'w') as temp_file:
temp_file.write(user_session_token)
# File is readable/writable only by the owner
process_data(temp_path)
finally:
os.unlink(temp_path)<?php
// Vulnerable: creates temp file in world-writable directory
$temp_file = sys_get_temp_dir() . '/cache_' . uniqid() . '.tmp';
file_put_contents($temp_file, $api_key);
// File permissions default to system umask (often 0644)
// Any user can read the API key
process_cache($temp_file);
unlink($temp_file);
?>Why it's vulnerable:
The file is created with default permissions (typically readable by all users) in a shared temporary directory. The API key is exposed to other processes and users.
<?php
// Fixed: create temp file with restrictive permissions
$temp_file = tempnam(sys_get_temp_dir(), 'cache_');
chmod($temp_file, 0600); // Owner read/write only
file_put_contents($temp_file, $api_key);
// File is readable/writable only by the owner
process_cache($temp_file);
unlink($temp_file);
?>mkstemp(), tempfile.mkstemp()) that atomically create files with restrictive permissions (0600 or equivalent).
/tmp or %TEMP%.
Check your application's temporary file locations (e.g., /tmp, %TEMP%, or custom temp directories) for files with overly permissive permissions (world-readable or world-writable). Use ls -la /tmp or dir %TEMP% to inspect. Look for unexpected files created by your application, or audit logs showing access to temporary files by unintended users. If your application processes sensitive data and stores it temporarily, verify that those files are not readable by other system users.
