This weakness occurs when software attempts to access a resource by name or reference, but that name resolves to something other than what the developer…
This weakness occurs when software attempts to access a resource by name or reference, but that name resolves to something other than what the developer intended. The mismatch can arise from caching, symbolic links, file system aliasing, or race conditions between name resolution and access. An attacker who can control or predict how names resolve may trick the application into accessing, modifying, or disclosing unintended files or objects.
The vulnerability emerges when there is a gap between the time a name is validated and the time it is actually used to access a resource—or when the resolution mechanism itself is not deterministic. For example, a symbolic link might point to one location when checked, but be changed before the file is opened. A cached DNS entry might resolve to an attacker-controlled server. A relative path might resolve differently depending on the current working directory. In each case, the application trusts that the name it validated is the same name that will be resolved at access time, but that assumption breaks down.
Depending on the context, this weakness can lead to unauthorized file access, information disclosure, privilege escalation, or denial of service. An attacker might read sensitive configuration files, overwrite critical application code, or cause the application to execute or serve malicious content. In multi-tenant or shared-hosting environments, one user might gain access to another user's data through symlink or path-resolution attacks.
import os
# User provides a filename
user_file = input("Enter filename: ")
# Check if file exists
if os.path.exists(user_file):
# Attacker could have changed a symlink between check and open
with open(user_file, 'r') as f:
data = f.read()
print(data)Why it's vulnerable:
The code checks that a file exists, but an attacker can replace a symlink or change the file system between the os.path.exists() call and the open() call, causing the application to read an unintended file.
import os
user_file = input("Enter filename: ")
allowed_dir = "/var/app/uploads"
# Resolve to absolute path and verify it stays within allowed directory
real_path = os.path.realpath(user_file)
allowed_path = os.path.realpath(allowed_dir)
if real_path.startswith(allowed_path):
with open(real_path, 'r') as f:
data = f.read()
print(data)
else:
print("Access denied: path outside allowed directory")<?php
$user_file = $_GET['file'];
// Check if file exists
if (file_exists($user_file)) {
// Symlink could point elsewhere by the time we read
$content = file_get_contents($user_file);
echo $content;
}
?>Why it's vulnerable:
The code verifies the file exists but does not resolve symlinks or verify the final target. An attacker can use a symlink to cause the application to read a file outside the intended directory.
<?php
$user_file = $_GET['file'];
$allowed_dir = '/var/www/uploads';
// Resolve symlinks and verify the real path is within allowed directory
$real_path = realpath($user_file);
$allowed_real = realpath($allowed_dir);
if ($real_path && strpos($real_path, $allowed_real) === 0) {
$content = file_get_contents($real_path);
echo htmlspecialchars($content, ENT_QUOTES, 'UTF-8');
} else {
echo "Access denied";
}
?>realpath() (PHP) or os.path.realpath() (Python) to follow symlinks and normalize paths.
Check application logs for repeated attempts to access files outside expected directories, or for unusual path patterns (e.g., ../, ..\\, or symlink names). Review the file system for unexpected symbolic links in upload directories or other user-writable locations. If your application reads configuration files or sensitive data by name, verify that those names always resolve to the intended files and not to attacker-controlled locations.
