What Is Path Traversal (Directory Traversal)?

Path traversal, also called directory traversal, is a web security flaw that lets an attacker read or sometimes write files outside the directory an application is supposed to be limited to, by manipulating file-path input with sequences like ../ (dot-dot-slash). Because so many applications build file paths from user input, a path traversal bug can expose source code, configuration files, credentials, and secrets, and it is tracked as CWE-22, improper limitation of a pathname to a restricted directory. In the worst cases it allows reading arbitrary files anywhere the server process can reach.

Understanding path traversal matters because it remains one of the most common and most damaging web vulnerabilities, and it is actively exploited. In September 2026, GitLab patched CVE-2026-85706, a CVSS 10.0 path traversal in its repository commits API that let unauthenticated attackers read arbitrary files in a single request; CISA added it to the Known Exploited Vulnerabilities catalog within days. That case shows why a "just a file read" bug can rate a perfect 10.

How does a path traversal attack work?

An application takes a filename from user input and joins it to a base directory to open a file. If it does not properly validate that input, an attacker supplies a path like ../../../../etc/passwd, and each ../ climbs one directory up, walking out of the intended folder to somewhere sensitive. Attackers also use encoded variants, such as %2e%2e%2f or double-encoding, to slip past naive filters that only block the literal ../ string. On Windows the same idea uses backslashes and paths like ....\windows\win.ini.

What is the difference between path traversal and local file inclusion?

Path traversal lets an attacker read the contents of files outside the intended directory. Local file inclusion (LFI) goes further: the application includes and executes a file the attacker points to, which can lead to code execution, especially if the attacker can also control what gets written to a file the server will later include. Path traversal is often the first step, and whether it ends in file disclosure or code execution depends on how the retrieved path is used.

How do you prevent path traversal?

Avoid using user input to build file paths at all where possible. When you must, validate input against a strict allowlist of permitted filenames or identifiers rather than trying to blocklist bad characters, and after resolving the full canonical path, verify it still sits inside the intended base directory before opening it. Decode input fully before validating so encoded traversal cannot bypass checks, run the application with least privilege so a traversal reaches as little as possible, and keep frameworks and platforms patched, because vendor path traversal bugs like CVE-2026-85706 are fixed by updates.

Frequently asked questions

What can an attacker do with path traversal? Typically read sensitive files such as configuration, credentials, tokens, and source code. On a platform that stores secrets, that can be enough to compromise other systems, and in some cases traversal can be chained to write files or achieve code execution.

Is path traversal the same as SQL injection? No. Both come from unvalidated input, but SQL injection manipulates database queries, while path traversal manipulates file paths on the server's filesystem. They are different vulnerability classes with different targets.

How common is path traversal? Very. It appears regularly in OWASP guidance and in real advisories, and multiple maximum-severity path traversal flaws in major products have been disclosed and exploited, including GitLab CVE-2026-85706 in 2026 and CVE-2023-2825 in 2023.

Our read

Path traversal endures because building file paths from user input is everywhere, and one missed validation can turn a routine file handler into an arbitrary-read primitive over an entire server. The teams that avoid it treat all path input as hostile: allowlist the values they accept, canonicalize and re-check the resolved path against the intended directory, decode before validating, and run with least privilege so a slip exposes as little as possible. As the GitLab 10.0 case shows, the file an attacker reads is often the secret that unlocks everything else, so the goal is to prove your file access is confined rather than assume the framework confines it.

Weakness definition per CWE-22; attack detail per OWASP; exploitation status per CISA KEV. Sources linked above.

Related: What is a web shell? and How to prioritize vulnerabilities.