Path traversal

Path traversal (also called directory traversal) is a vulnerability where an application lets user input control a file path in an unsafe way, so an attacker can escape the intended directory and access files elsewhere on the server.​

What path traversal allows

By inserting sequences like ../ (or encoded variants) into a filename parameter, an attacker can move up the directory tree and read sensitive files such as configuration files, credentials, source code, or OS files like /etc/passwd or C:\Windows\win.ini. In some implementations, the same flaw can also let an attacker write or overwrite files, which may lead to tampering with application behavior or even remote code execution.​

Why it happens

Path traversal usually occurs when user-supplied filenames (for example, ?file=report.pdf) are concatenated directly into filesystem paths without proper normalization, validation, or restriction to a safe base directory. Insufficient filtering of ../, alternate encodings, or absolute paths means the application trusts the user's idea of "which file to open," effectively exposing the server's directory structure beyond the intended web root.

Unauthorized file reading through traversal sequences

Unauthorized file reading through path traversal uses sequences like ../ (or encoded equivalents) injected into filename parameters to escape the intended directory and reach sensitive system or application files.​

Basic traversal payloads

Attackers append ../ multiple times to climb up from a web-accessible directory (for example /var/www/files/) to the filesystem root, then navigate to targets. Common examples include:​

GET /download?file=../../../etc/passwd
GET /download?file=../../../../windows/win.ini

These resolve to absolute paths like /etc/passwd (Unix users) or C:\Windows\win.ini (Windows config) if the app concatenates the input directly to a base path without validation.​

Bypassing filters with encodings

Filters blocking ../ can be evaded using URL encoding (%2e%2e%2f), double encoding (%252e%252e%252f), Unicode (..%c0%af), or null bytes (....//). Examples:​

GET /download?file=..%2f..%2f..%2fetc%2fpasswd
GET /download?file=....//....//....//windows/system32/drivers/etc/hosts

On Windows, backslashes (..\) also work, and absolute paths like C:\inetpub\wwwroot\web.config bypass relative traversal entirely.

Practical difficulties in triggering traversal-based file reads

Practical difficulties in triggering traversal-based file reads often stem from path normalization, permissions, encoding mismatches, and response blindness.​

Path normalization and filtering

Many languages and frameworks automatically resolve ../ sequences before file access using functions like realpath(), os.path.abspath(), or Path.normalize(), which strip traversal attempts and block exploits. Basic filters blocking ../, .., or absolute paths are common, forcing attackers to chain encodings (%2e%2e%2f, double/triple encoding, Unicode variants like %c0%af, or null bytes %00) that may break across proxies, WAFs, or different app layers.​

File permissions and OS restrictions

Even if traversal reaches a target like /etc/passwd, the web server process (often running as www-data or low-privilege user) may lack read access to sensitive files, returning empty responses or 403 errors. Windows UAC, container isolation (Docker), or chroot jails further restrict filesystem visibility, so attackers must guess the exact server OS, directory structure, and process context through trial-and-error.​

Blind exploitation and confirmation challenges

Responses often show generic errors, truncated content, or nothing useful, making it hard to confirm success without visible file contents. Base path prefixes (must start with /var/www/files/) or required extensions (.png) force payloads like /var/www/files/../../../etc/passwd or ../../../etc/passwd%00.png, and attackers need the exact number of ../ to reach targets without overshooting.

Path traversal mitigation

Path traversal mitigation centers on never trusting user input for filesystem paths, using allowlists, normalization, and isolation to block traversal entirely.​

Avoid user input in filesystem APIs

The strongest defense is avoiding user-supplied filenames for file operations altogether—use IDs or hashes to map to predefined paths instead of accepting direct paths. When file access is unavoidable, prepend a fixed base directory (for example /var/www/files/) and use platform APIs like realpath(), os.path.abspath(), or Path.resolve() to canonicalize/normalize the path before access, rejecting anything that doesn't start with the expected base.​

Whitelist validation and input sanitization

Validate filenames against a strict allowlist of permitted characters (alphanumeric, underscores, hyphens only—no /, \, ., ..) and reject absolute paths or suspicious sequences outright. Strip or block traversal patterns like ../, %2e%2e%2f, null bytes (%00), and encodings before processing, and enforce required extensions or prefixes if needed.​

Environment hardening

Run web processes as low-privilege users without read access to sensitive files, use chroot jails or containers to limit filesystem visibility, and store no configs/secrets in web-accessible directories. Complete the defense with WAF rules blocking common traversal payloads and logging all file access attempts for anomaly detection.​