Path Traversal vulnerabilities remain one of the most common ways attackers move from limited application input to arbitrary file access. They are conceptually simple, yet persist because developers continue to trust filenames, file paths, archive contents, and storage metadata more than they should.
CWE-22 occurs when software uses externally controlled input to construct file or directory paths without properly restricting access to the intended filesystem location.
In practical terms:
The attacker turns a “read this file” feature into “read any file the process can access.”
This article breaks down how path traversal works, why developers still introduce it, modern exploitation techniques, framework-specific mitigations, and secure file-handling patterns.
What Is Path Traversal?
Path Traversal happens when an attacker manipulates path input to escape the directory an application intended to use.
Unsafe example:
filename = request.args["file"]
path = "/var/www/uploads/" + filename
If the attacker supplies:
../../../etc/passwd
The resulting path becomes:
/var/www/uploads/../../../etc/passwd
Which resolves to:
/etc/passwd
The attacker has escaped the upload directory.
How Path Traversal Actually Works
The root problem is that filesystem path resolution interprets traversal tokens such as .. as directory navigation.
Attack Flow
- Application accepts user-controlled filename/path
- Application concatenates it into filesystem path
- OS resolves traversal sequences
- Path escapes intended directory
- Unauthorized file access occurs
Visual: Path Traversal Data Flow
Why Developers Still Get Path Traversal Wrong
“We Sanitized ../”
Developers often block literal ../ but miss bypasses:
- URL encoding
- Double encoding
- Unicode variants
- Backslash separators on Windows
- Mixed separator normalization
Trusting Uploaded Filenames
User-uploaded file names are attacker-controlled input.
Archive Extraction Assumptions
ZIP/TAR extraction often trusts internal archive paths.
This enables Zip Slip:
../../../../webroot/shell.jsp
Framework Helper Misuse
Developers assume helper functions automatically constrain paths.
Many simply normalize paths—they do not sandbox them.
Modern Exploitation Techniques
Sensitive File Disclosure
Common targets:
/etc/passwd.env- Config files
- Secrets / API keys
- Source code
Template / Code Inclusion
Traversal may reach executable templates/scripts.
Log Poisoning + Traversal
Combine writable log file injection with traversal/LFI to execute code.
Archive Extraction Abuse
Malicious ZIP/TAR overwrites arbitrary files.
Symlink Abuse
Traversal controls path to symlinked sensitive locations.
Visual: Path Traversal Exploitation Chain
Framework-Specific Mitigations
Canonicalize Then Validate
Resolve path before checking:
requested = os.path.realpath(base + "/" + user_input)
if not requested.startswith(base):
deny()
Validation must occur after canonicalization.
Use Framework File Abstractions Carefully
Prefer safe path join helpers—but verify sandbox enforcement.
Archive Extraction Validation
Validate every extracted entry:
- Canonicalize destination
- Reject traversal outside extraction root
Secure Coding Examples
Unsafe
path = "/uploads/" + filename
open(path)
Safer
path = os.path.realpath(os.path.join(BASE_DIR, filename))
if not path.startswith(BASE_DIR):
raise Exception("Invalid path")
Best Practice: Indirect References
Store files by internal ID:
file = db.lookup(file_id)
open(file.storage_path)
Avoid exposing filesystem paths entirely.
Defense in Depth
Least Privilege Filesystem Permissions
Application should not access sensitive OS/system files.
Container / Sandbox Isolation
Restrict process filesystem visibility.
Separate Upload Storage
Store uploads outside webroot / app directories.
Detect Suspicious Paths
Alert on:
../%2e%2e%2f- Encoded traversal sequences
- Unexpected path normalization failures
Final Thoughts
Path Traversal remains dangerous because it converts seemingly harmless file operations into arbitrary filesystem access.
It persists because:
- Developers underestimate path normalization complexity
- Input filtering is brittle
- Archive extraction is frequently overlooked
- Filesystem assumptions vary by platform
The principle remains simple:
If user input influences filesystem paths, you must verify where that path resolves—not just what it looks like.
String filtering is not enough.
Filesystem resolution is what matters.
3 thoughts on “CWE-22: Path Traversal — When Users Escape the Filesystem Sandbox”