Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot

Home / Knowledge hub / Path traversal

Knowledge hub

Path traversal

Using a crafted file name to reach files outside the intended folder.

What it means

Path traversal uses a crafted file name to step outside the folder an application meant to serve. The classic form is a run of ../ segments, each meaning go up one level. Repeat it enough and the path reaches the top of the disk, then heads back down somewhere interesting.

It turns up wherever a name from a request becomes a location on disk: a download link, a file preview, a template chooser, an image resizer, an import feature, an export.

Why it matters

An ordinary file feature becomes a way to read the server. Configuration files, database credentials, private keys, environment files and your own source code all sit in predictable places on a standard installation.

Source code makes everything afterwards easier, because an attacker reads your checks instead of guessing at them. If the feature writes files rather than reading them, it gets worse again: a file placed in the right directory can become code the server runs.

How it shows up

The vulnerable pattern joins a name from the request onto a base directory and opens the result. The near-miss fix strips ../ from the input, and CWE-22 warns against exactly that: strip sequentially and a string such as ....// leaves a working ../ behind after filtering.

Better not to treat the supplied name as a path at all. Look an identifier up and serve the file it points to. If you must build a path, resolve it first and confirm it still sits inside the intended directory before opening anything, which is what PortSwigger recommends. Uploads deserve the same care, since a name from a user should never decide where a file lands.

Questions people ask

Path traversal, answered

Is path traversal the same as local file inclusion?

They overlap and the outcome differs. Path traversal reads a file the application was never meant to serve. Local file inclusion gets a file executed by the application's include mechanism.

Reading configuration is bad. Getting a file executed usually ends in remote code execution.

Do modern frameworks not handle this already?

They help, and they do not close it. The weakness still appears in widely used frameworks and in anything that unpacks archives or resolves paths itself.

Container and cloud builds added new places for it, such as archive extraction writing outside its target directory.

Is stripping ../ enough?

No, and CWE-22 says so directly. Removing the sequence once can leave characters behind that recombine into a valid one, and some systems accept a backslash as a separator too.

Encoded forms defeat a filter that only looks for the plain text version.

What can an attacker actually read?

Whatever the application's own user can read. On a typical deployment that includes environment files, connection strings, private keys and the source code itself.

That is why a finding here escalates quickly even though the request looks harmless.

Does it apply to uploads as well as downloads?

Yes, and the write side is worse. A file name arriving from a user should never decide where the file gets stored.

Generate the name yourself, store it under a directory the application controls, and keep the original name only as a label in the database.

Which files can your app reach?

We test file handling beside injection and configuration, and each finding arrives with the request that escaped the folder and whatever came back. Ask about a pilot on one application.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.