Link Following
CWE-59: Improper Link Resolution Before File Access ('Link Following')
CWE-59 refers to a security vulnerability that occurs when an application resolves symbolic or hard links to files before properly validating the link’s target. This can allow attackers to control which file or directory the application accesses, potentially leading to unauthorized access to sensitive files, privilege escalation, or other types of attacks.
How It Works:
This vulnerability arises when a program opens a file path (which may be controlled by the user) and fails to check whether the path refers to a symbolic link. Instead, the program blindly follows the link and accesses the file it points to, without any validation. If an attacker can control or manipulate the symbolic link’s target, they can trick the program into accessing sensitive files or data, such as system files that should be protected.
Vulnerable Scenario (Local and Remote)
1. Local Attack ( which is likely ) :
Vulnerable Application: A local file viewer or editor that opens any file without validating whether it is a symlink.
Attack Steps:
The attacker creates a symbolic link (
symlink.txt
) that points to/etc/passwd.
The attacker uploads the symbolic link to the server or places it within a directory accessible by the vulnerable application.
The application opens the symbolic link as if it were a regular file, and it ends up reading
/etc/passwd
.
The attacker gains unauthorized access to sensitive information, such as user credentials stored in
/etc/passwd
.

2. Remote Attack (via HTTP Request):
Vulnerable Web Application: A file upload service where users can upload pictures for sharing, without checking for symbolic links.
Attack Steps:
The attacker uploads a symbolic link (e.g.,
user_file.txt
) through the web interface. This symlink points to/etc/passwd
on the server.The web application stores the file in the server's file storage system without validating whether it's a symlink.
The attacker, knowing the file's location (e.g.,
/uploads/user_file.txt
), requests the file via an HTTP request:GET /uploads/user_file.txt HTTP/1.1 Host: vulnerable-app.com
The application, unaware that
user_file.txt
is a symlink, follows it and opens/etc/passwd
instead of the intended file.
The attacker can access sensitive system information through the web interface, such as user credentials stored in
/etc/passwd:
HTTP/1.1 200 OK
Date: Fri, 11 Jan 2025 13:45:00 GMT
Server: Apache/2.4.7 (Ubuntu)
Content-Type: text/plain; charset=UTF-8
Content-Length: 122
root:x:0:0:root:/root:/bin/bash
user:x:1001:1001:user:/home/user:/bin/bash
Note: This scenario assumes the server's file system supports symbolic links and the upload mechanism does not sanitize or block symlinks. On some systems, uploading symlinks may require special permissions or may not be supported.
Vulnerable Application Example
Example: a local web server that lets users upload files.
Normal Behavior
You upload a file
photo.jpg
→ server saves it as/uploads/photo.jpg
Later, when you or others download it, the server reads
/uploads/photo.jpg
and returns it.
No problem here if it’s a real file.
What happens if the app does NOT check for symlinks?
The app just opens
/uploads/photo.jpg
without checking if it’s actually a shortcut.If an attacker can somehow upload a symlink instead of a real file, bad things can happen.
Attacker’s Trick
Let’s say the attacker wants to steal /etc/passwd
.
Attacker uploads a symlink called
photo.jpg
that points to/etc/passwd
.
Example:
ln -s /etc/passwd photo.jpg
Then they upload photo.jpg
to the server.
Server stores it
If the server:
Saves this symlink on the disk
Does NOT sanitize it (doesn’t check if it’s a symlink)
then later, when anyone requests:
GET /uploads/photo.jpg
The server says:
“OK, let me open
/uploads/photo.jpg
...” OS sees it’s a symlink → follows it → actually opens/etc/passwd
!
The server then sends /etc/passwd content to the attacker!
Result: Data Leakage
Now the attacker sees:
root:x:0:0:root:/root:/bin/bash
...
Impact and Exploitation
As demonstrated, the vulnerable application opens /uploads/user_file.txt
without checking whether it’s a symbolic link. Since /uploads/user_file.txt
is a symlink to /etc/passwd
, the application reads and prints the contents of /etc/passwd
, exposing sensitive system information. This results in information disclosure and can potentially lead to privilege escalation or further attacks.
Mitigation Strategy
To mitigate this vulnerability, always verify the target of symbolic links before accessing them. In Python, this can be done using os.path.islink()
to detect symbolic links and reject or handle them securely.
Here’s a secure version of the code:
import os
def process_file(file_path):
"""Secure function that checks for symbolic links before opening the file"""
if os.path.islink(file_path):
print("Error: Symbolic link detected. Aborting file access.")
return
print(f"Opening file: {file_path}")
try:
with open(file_path, 'r') as f:
data = f.read()
print(data)
except Exception as e:
print(f"Error: {e}")
# Simulated file upload path
uploaded_file = '/uploads/user_file.txt'
process_file(uploaded_file)
In this version, the program first checks whether the file is a symbolic link using os.path.islink()
. If it is, the program aborts the operation and prevents accessing the target file, blocking exploitation.
Resources
Last updated