Path traversal, also called directory traversal, is a vulnerability in which an application builds a file system path from user-controlled input without proper restriction, allowing an attacker to access files and directories outside the intended location. By inserting sequences such as ../ or absolute paths, the attacker can read configuration files, source code or credentials, and in write scenarios can overwrite files or plant code.
In application security, path traversal is classified as CWE-22 and falls under broken access control in the OWASP Top 10. It is conceptually simple, yet it keeps reappearing in web applications, file upload handlers, archive extractors and network appliances because path handling is full of edge cases across operating systems, encodings and frameworks.
How path traversal works
The flaw appears when code concatenates a base directory with a user-supplied name and passes the result to a file API. If a download handler serves /var/www/files/ plus the name parameter, a request for ../../../etc/passwd resolves to /etc/passwd, because the operating system interprets each .. as a step up to the parent directory.
The application does nothing unusual from its own point of view: it opens a path and returns the content. The vulnerability lies in the gap between the path the developer imagined and the path the operating system resolves. Anything the application’s process account can read becomes reachable, which is why running services with least privilege limits the damage.
The table lists typical vulnerable entry points and what an attacker gains from each.
| Entry point | Typical example | Potential impact |
|---|---|---|
| File download parameters | ?file=report.pdf | Reading arbitrary files |
| Template or language selection | ?lang=en mapped to a file | Source disclosure or file inclusion |
| File upload names | Uploaded file named with ../ | Overwriting files, web shells |
| Archive extraction | ZIP entry named ../../app/config | Writing outside target folder (Zip Slip) |
| Static file servers | Encoded traversal in the URL path | Exposure of system files |
Encoding tricks and filter bypasses
Naive defenses that search for the literal string ../ are easily bypassed, because the same path can be written in many forms that decode or normalize to traversal. Attackers try each variant until one slips past the filter but is still resolved by the file system.
| Technique | Example input | Why it works |
|---|---|---|
| URL encoding | %2e%2e%2f | Decoded after the filter runs |
| Double encoding | %252e%252e%252f | Decoded twice by different layers |
| Backslash separators | ..\..\windows\win.ini | Windows accepts both separators |
| Nested sequences | ....// | Single-pass removal leaves ../ behind |
| Absolute paths | /etc/passwd | Joining functions may discard the base |
| Overlong UTF-8 | %c0%ae%c0%ae/ | Lenient decoders map it to dots |
The absolute path case surprises many developers: in several languages, joining a base with an absolute path returns the absolute path unchanged, so join("/srv/files", "/etc/passwd") silently ignores the base directory.
Path traversal compared with related vulnerabilities
Path traversal is often confused with file inclusion and insecure direct object references, since all three involve user input that selects a resource. The difference lies in what the input controls and what happens to the resource.
| Vulnerability | Input controls | Typical result |
|---|---|---|
| Path traversal | A file system path | Reading or writing files outside the intended folder |
| Local file inclusion | A file that the interpreter executes | File disclosure or code execution |
| IDOR | An object identifier | Access to another user’s record |
| SSRF | A URL fetched by the server | Access to internal network services |
In practice these flaws chain together. A traversal that reads an application’s configuration may expose database passwords or signing keys, turning a read-only file disclosure into full compromise.
Preventing path traversal
Robust prevention avoids building paths from raw input altogether. When that is not possible, the application must canonicalize the path and verify containment before opening it. The options below are listed from strongest to weakest.
| Approach | How it works | Strength |
|---|---|---|
| Indirect references | Map an ID to a stored file name server-side | Strongest; input never becomes a path |
| Allowlist of names | Accept only known file names | Strong for fixed sets |
| Canonicalize and check prefix | Resolve the real path, confirm it is inside the base | Strong if done after full resolution |
| Character allowlist | Permit only letters, digits and a single dot | Useful extra layer |
| Blocklist of `../` | Remove or reject known patterns | Weak; easily bypassed |
Canonicalization must use the function that resolves symbolic links and relative segments, such as realpath or its equivalent, and the containment check must compare whole directory components so that /srv/files-old is not accepted as inside /srv/files. Newer operating system interfaces, such as Linux openat2 with the RESOLVE_BENEATH flag, enforce containment in the kernel itself.
- Run the service under a dedicated account that cannot read secrets it does not need.
- Store uploads outside the web root and give them generated names.
- Validate archive entries before extraction and reject any entry that resolves outside the target.
- Test with automated scanners and code review, since static analysis catches many tainted path flows.
Detecting attempts and assessing impact
Traversal attempts leave characteristic patterns in access logs, such as repeated .. sequences, encoded dots or requests for well-known files like /etc/passwd and win.ini. Web application firewalls block many of these patterns, but they should be treated as a safety net rather than a fix, because new encodings and framework quirks keep appearing.
When a traversal vulnerability is confirmed, the impact assessment should assume that every file readable by the service account was exposed. Rotating credentials found in configuration files, reviewing logs for exploitation and checking for newly written files are standard steps.
Understanding it simply
Imagine a library clerk who fetches any book you name from one specific shelf. Path traversal is like asking for the book three rooms back, in the locked office, and the clerk fetching it without checking where the request leads.
The two dots in ../ simply mean go up one folder. If an application does not check where a requested path really ends up, a visitor can reach files that were never meant to be shared, such as passwords or private settings.
Applied in practice
During a routine penetration test of an internal document portal, a tester notices that invoices are downloaded through a URL parameter containing the file name. Replacing the name with ..%2f..%2f..%2fapp%2fconfig%2fsettings.yaml returns the application’s configuration file, including the database password and an API signing key.
The development team fixes the issue by replacing file names with random document IDs stored in the database, resolving the final path with realpath as an additional check, and moving the configuration secrets into a secrets manager. The exposed database password and signing key are rotated the same day, and a log review confirms that no one had exploited the flaw before the test.