// THECYBERARYAN — VULNERABILITY SERIES

PATH TRAVERSAL — ESCAPING FOLDERS LIKE A CYBER NINJA

Path Traversal explained in brutal, neon clarity — how ../ turns into a skeleton key for the filesystem.

📂 FROM “ONE FILE” TO “ALL FILES”

Path Traversal is that vulnerability where the server politely asks:

“Which file would you like?”

And you, being you, respond with:
“Yes.”

definition

Path Traversal = using sequences like ../ to escape the intended directory and read files you were never supposed to see.

The app says “only open files from this safe folder.” You say “cool, but what if I go outside the folder?” The OS shrugs and says “Path is valid, go ahead.”

WHY PATH TRAVERSAL EXISTS (BLUNT VERSION)

Because somewhere, someone concatenated user input directly into a file path. Something like:

GET /download?file=report.pdf

Backend logic:

base = "/var/www/app/reports/"
file = base + request.GET["file"]
open(file)

Now if you send:

file=invoice_123.pdf

It becomes:

/var/www/app/reports/invoice_123.pdf

Nice and normal. But if you send:

file=../../../../etc/passwd

It becomes:

/var/www/app/reports/../../../../etc/passwd

Filesystem: “Yeah that’s legit, here’s /etc/passwd.” App: confused but compliant. You: quietly smiling.

impact snapshot

If you can reach files like /etc/passwd, configs, source code, or credentials, you’re no longer just “a user”. You’re basically the server’s nosy roommate.

WHERE PATH TRAVERSAL LOVES TO HIDE

Any time you see “file” or “path” in a parameter, treat it as suspicious by default.

Common hotspots

/download?file=report.pdf
/view?template=invoice.html
/image?name=avatar.png
/logs?file=access.log
Backup import/export endpoints
Custom theme/template loaders

The mental shortcut is:
“If the app reads a file based on my input, it might read ANY file based on my input.”

CLASSIC PAYLOADS (THE “../” GANG)

Linux targets:

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

URL-encoded versions:

..%2f..%2f..%2f..%2fetc%2fpasswd
..%2f..%2f..%2f..%2fetc%2fhosts

Double-encoded (for smart-ish filters):

..%252f..%252f..%252f..%252fetc%252fpasswd

Windows vibes:

..\..\..\..\Windows\win.ini
..\..\..\..\Windows\System32\drivers\etc\hosts

REALISTIC ATTACK FLOW — FILE DOWNLOAD ENDPOINT

Normal user:

GET /download?file=invoice_2024_01.pdf

Hacker brain:

GET /download?file=../../../../etc/passwd

If the response looks like:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...

translation

That’s not just a “bug”. That’s “we trusted user input with our filesystem” level misconfiguration.

WHAT TO READ AFTER /ETC/PASSWD (THE GOOD PART)

/etc/passwd is proof-of-concept. The real treasure:

Application configs: config.php, settings.py, .env
Database credentials, API keys, SMTP creds
Source code files (to find more vulnerabilities)
Log files with tokens, debug data, stack traces

You’re basically speedrunning from “file read” → “full environment intel”.

BYPASSING BASIC FILTERS (WHEN DEVS TRY)

Common “defenses”:

Block literal ../
Strip ../ once
Allow only files ending in .pdf

Your options:

....// (normalizes to ../)
..%2f..%2f..%2f..%2fetc%2fpasswd
..%252f..%252f..%252f..%252fetc%252fpasswd (double encoding)
../../../../etc/passwd%00.pdf (older null-byte cases)

mindset

Don’t just try one payload. Try different encodings, extra dots, slashes, suffix tricks. Your job: confuse the filter, not yourself.

HOW DEV TEAMS SHOULD FIX IT (IN THEORY)

Use strict allow-lists of filenames, not raw paths from user input.
Map IDs → internal filenames server-side, instead of sending paths from user.
Canonicalize/normalize the final path and verify it stays inside the intended directory.
Run file-serving logic in heavily restricted directories/sandboxes.

golden rule

If the user can influence the filesystem path, you must assume they’ll try to walk out of it.

FAST HACKER CHECKLIST FOR PATH TRAVERSAL

Find parameters like file, path, log, template.
Start with ../ and basic payloads.
Try /etc/passwd (Linux) or win.ini (Windows) as a proof.
Escalate to configs, source code, and secrets.
Try encoded and double-encoded variations when blocked.

If you can prove sensitive file read reliably, you’ve got a strong, high-severity report in your hands.