This weakness occurs when software runs with permissions that differ from what the administrator or developer intended, usually because the runtime environment…
This weakness occurs when software runs with permissions that differ from what the administrator or developer intended, usually because the runtime environment assigns permissions automatically in unexpected ways. The result is that code executes with more (or sometimes fewer) privileges than necessary, creating a security gap. This is particularly dangerous in multi-user or containerized environments where permission inheritance and defaults can be misunderstood.
When an application or service starts, the operating system or runtime assigns it a set of permissions based on the user account running it, inherited environment variables, umask settings, or container/sandbox configurations. Developers often assume a specific permission model but don't explicitly verify or enforce it at runtime. For example, a script might be installed to run as root when only user-level permissions are needed, or a file created by the application might inherit overly permissive defaults from its parent directory. In containerized environments, a process might run as root inside the container even though the image was intended to use a non-root user. These mismatches between intended and actual permissions are often silent — the code works, but with unintended privilege levels.
If an application runs with elevated privileges it doesn't need, a vulnerability in that application (or in a library it uses) becomes a privilege-escalation vector. An attacker who compromises the application gains the permissions it was running under, potentially allowing them to modify system files, access other users' data, or install persistent backdoors. Conversely, if an application runs with insufficient permissions, it may fail silently or create world-readable files when they should be private, exposing sensitive data. In shared hosting or multi-tenant environments, permission misconfiguration can allow one tenant to access another's files or resources.
import os
import tempfile
# Application creates a temporary file for storing session data
temp_file = tempfile.mktemp(prefix="session_", suffix=".tmp")
with open(temp_file, "w") as f:
f.write(user_session_data)
# File inherits default umask, potentially world-readable
# Application runs as root (unintended), so file is owned by rootWhy it's vulnerable:
The code doesn't explicitly set file permissions, relying on the system umask and the process's effective user ID. If the process runs as root (because it was started with sudo or installed setuid), the created file will be owned by root and may be readable by other users depending on umask.
import os
import tempfile
# Create temporary file with explicit restrictive permissions
fd, temp_file = tempfile.mkstemp(prefix="session_", suffix=".tmp")
os.chmod(fd, 0o600) # Owner read/write only
with os.fdopen(fd, "w") as f:
f.write(user_session_data)
# Verify the process is running as intended user, not root
if os.geteuid() == 0:
raise RuntimeError("This application must not run as root")<?php
// Web application creates a cache file
$cache_file = "/tmp/app_cache_" . $user_id . ".txt";
file_put_contents($cache_file, $cached_data);
// If the web server runs as root (misconfigured), file is owned by root
// and may be world-readable depending on server umask
?>Why it's vulnerable:
The code doesn't set explicit file permissions and assumes the web server runs as an unprivileged user. If the server is misconfigured to run as root, the created file inherits root ownership and default permissions, potentially exposing sensitive data.
<?php
// Create cache file with explicit restrictive permissions
$cache_file = "/tmp/app_cache_" . $user_id . ".txt";
file_put_contents($cache_file, $cached_data);
chmod($cache_file, 0600); // Owner read/write only
// Verify the web server is not running as root
$current_user = posix_getpwuid(posix_geteuid());
if ($current_user['name'] === 'root') {
error_log("Web server must not run as root");
exit(1);
}
?>chmod() (PHP) or os.chmod() (Python) immediately after creating sensitive files.
USER directive in the image; do not rely on implicit defaults.
Check your application's running process and file ownership: use ps aux or docker exec to verify the user running your application, and ls -la to inspect the ownership and permissions of files it creates. If you see files owned by root when they should be owned by a service account, or world-readable files containing sensitive data, your permissions may be misconfigured. Review your deployment logs and startup scripts for any sudo invocations or root-level service definitions that were not explicitly intended.
