Directory traversal (path traversal)

What is directory traversal?

Directory traversal – also called path traversal – is a web vulnerability that lets an attacker access arbitrary files on a server file system outside the web application’s intended directory, such as the document root or an approved upload folder. 

Directory (path) traversal is possible when an application uses untrusted input to build or select a path on the server file system. Successful attacks can expose sensitive data like configuration files, credentials, logs, or source code, and the information gained is often used to enable follow-on attacks. While traversal is frequently associated with reading files, in some scenarios it can, when combined with other weaknesses or unsafe server behavior, contribute to more severe outcomes, up to and including remote code execution.

How directory traversal attacks work

Directory traversal is a boundary-breaking bug. The application intends to allow access only to a specific directory (for example, a folder of user-uploaded images), but a crafted path causes the application to “escape” that directory and read from elsewhere on the filesystem. The usual starting point for traversal is the web root directory.

The importance of the web root

Websites and applications run on a web server that serves content from a location called the web document root or web root folder. The document root usually contains subdirectories for each hosted application.

Common default paths:

• On Linux/UNIX with Apache, a typical root folder is /var/www/
• On Windows with Microsoft IIS, a typical document root is C:\inetpub\wwwroot

Developers often write application code that accesses files under the web root or within an application subdirectory. A common example is storing user-uploaded images under a directory such as /var/www/my_app/images/ and then allowing other users to request an image by filename.

The exploit flow

A typical traversal vulnerability follows a simple pattern:

1. The application accepts a filename or path segment from an HTTP request (query string, form field, cookie, API parameter).
2. The application uses that input directly (or with only minimal input validation) to open a local file.
3. An attacker supplies a path that changes where the application reads from. In many cases, attackers use dot-dot-slash traversal sequences such as ../ or ..\.
4. The server reads the target file using the permissions of the web server process.
5. The application returns the file contents or reveals useful clues through error behavior.

Relative traversal vs absolute path targeting

Attackers can try to reach unintended files in two ways:

• Relative traversal uses parent directory sequences such as ../ on Linux/UNIX or ..\ on Windows to “climb” up the directory tree.
• Absolute path targeting attempts to supply a full filesystem path directly (for example, /etc/passwd on Linux/UNIX or C:\Windows\win.ini on Windows), assuming the application accepts it.

Example of a directory traversal attack

Below is an example of PHP code that contains a directory traversal vulnerability, followed by a path traversal attack that exploits it.

Vulnerable code

A developer wants users to read poems stored in text files on the web server. The poems are stored in a poems directory under the application. The following code in poems/display.php reads a file specified by the user and prints it:

<?php
 $file = $_GET["file"];
 $handle = fopen($file, 'r');
 $poem = fread($handle, filesize($file));
 fclose($handle);
 echo $poem;
?>

Because the filename is taken directly from the GET request, you would retrieve a poem called poem.txt using a URL like:

http://example.com/my_app/display.php?file=poem.txt

The attack payload

The application doesn’t sanitize the file parameter value, so an attacker manipulates it to escape the intended directory and read a sensitive file by sending:

http://example.com/my_app/display.php?file=../../../../etc/passwd

The display.php script traverses upward in the directory structure and then reads the /etc/passwd file with its list of operating system users on the server and sends it back to the attacker instead of a poem.

Path traversal variants and bypass techniques

Many traversal bugs are straightforward, but attackers often combine traversal with encoding tricks and platform-specific quirks to bypass weak filters or inconsistent normalization.

Common traversal patterns

The table below shows common traversal approaches. These examples are illustrative only – real payloads will vary by framework, server, and how the application processes input.

Where traversal shows up most often

Traversal vulnerabilities are most common in features that handle local files, such as:

• File download, export, and “view document” endpoints
• Image retrieval and thumbnail generation
• Log viewers and diagnostic endpoints
• Backup and restore features
• Template loading or theme selection
• Embedded web software such as device management portals and remote administration interfaces

Directory traversal vs local file inclusion (LFI)

Directory traversal is often confused with local file inclusion (LFI) because both vulnerabilities can involve attacker-controlled file paths. Here’s how they differ:

• LFI means an attacker can include a local file via a dynamic include mechanism, often located within the document root directory and its subdirectories but potentially elsewhere, too. Depending on the language and configuration, “including” a file may also involve interpreter behavior.
• Directory traversal means an attacker can access files outside the intended directory boundaries, typically outside the document root, by escaping the allowed path.

In practice, LFI and directory traversal often appear together and frequently share the same root causes of allowing paths to local files to be passed through user-controlled input and missing access control on file-retrieval functionality.

Why directory and path traversal vulnerabilities still matter

Traversal is sometimes dismissed as “just file read,” but the information disclosed is often exactly what attackers need to escalate.

Real-world impact of traversal attacks

The direct outcome of a successful directory traversal attack is unauthorized access to sensitive information. That information may be valuable on its own (for example, confidential documents or private images stored on the server) or it may enable follow-on attacks such as:

• Credential theft from configuration files
• Discovery of internal services, hosts, and paths for lateral movement
• Targeted exploitation based on OS and software versions
• Privilege escalation using exposed secrets or operational data

In some cases, traversal can be part of an exploit chain that results in remote code execution, depending on the affected software and surrounding conditions.

What files attackers look for

Attackers commonly probe for files that reveal system and application context. On Linux-based web servers, the following files are frequent targets because they are typically readable:

• /proc/version – Linux kernel version (useful for matching known exploits)
• /proc/mounts and /etc/fstab – mounted filesystems (useful for locating additional targets)
• /proc/net/arp – ARP table (useful for discovering connected systems)
• /proc/net/tcp and /proc/net/udp – active connections (useful for mapping services)

Attackers also often hunt for application configuration files, environment dumps, secrets, and logs that may contain API keys, database credentials, tokens, or internal URLs.

Automation lowers the bar for traversal

Traversal is easy to automate using a vulnerability scanner or by fuzzing, i.e. sending many common payloads to many endpoints until something works. Tools such as DotDotPwn exist specifically to probe for traversal paths, so attackers do not need advanced skills to find and exploit weak file-handling logic.

How to detect directory traversal vulnerabilities

The best detection approach depends on whether you are dealing with known vulnerable software or trying to find unknown issues in custom code.

If you run third-party software

If you rely on commercial or open-source products and do not develop the software, start by identifying the exact product version and checking vendor advisories and vulnerability databases. If the version has a CVE and is known to be vulnerable to a traversal issue, you should assume you are exposed until you patch.

You can identify versions manually or with security tooling, for example, software composition analysis (SCA) for web application components or network scanners for networked systems.

If you build software or want to find previously unknown issues

To confirm a traversal vulnerability in a custom application or to discover unknown vulnerabilities in a known application, you need evidence that the issue is exploitable in practice. This can be done through:

• Manual security testing by qualified testers
• Automated application security testing that can safely validate exploitability by confirming a controlled file access outcome

Focus testing on endpoints and functions that accept filenames, file paths, or directory selections.

How to prevent and detect directory traversal

Preventing traversal is primarily about avoiding untrusted path input and enforcing strict file-access boundaries.

Secure design and coding patterns

Adhering to these patterns can remove or greatly reduce traversal risk:

• Avoid passing filenames or paths in user input whenever possible, including indirect inputs such as cookies.
• Use indirect references: store server-side file paths in a database and accept only record identifiers, tokens, or mapped keys from the client.
• Use URL mappings or routing that does not expose filesystem structure to users.

Secure ways of accepting filenames

When accepting user-controlled file identifiers is unavoidable, you can apply hardening rules to minimize risk:

• Use allow-lists (whitelists) to restrict requests to a known set of safe filenames or generated identifiers.
• Enforce an allow-listed base directory. Build paths only from a trusted base path and a constrained file identifier.
• Canonicalize before checking. Normalize the path and verify that the resolved path remains within the allowed base directory.
• Handle symlinks deliberately. Consider how symbolic links could allow escapes even when paths look safe.
• Apply the principle of least privilege. Ensure the web server process has the minimum permissions required so that sensitive files are not readable even if a traversal bug exists.

What not to rely on for traversal prevention

Avoid blacklisting, simple filtering, and “block special characters” approaches. Attackers can often bypass these controls with encoding and path-manipulation tricks. Similarly, extension-based checks are easy to subvert and do not solve the core boundary problem.

Traversal detection and monitoring

A defense-in-depth strategy will help you catch issues earlier and spot exploitation attempts:

• Add security testing coverage for file-handling code paths and endpoints that accept file identifiers.
• Log and alert on repeated traversal-like patterns and unusual error spikes on file-access endpoints.
• Rate-limit and protect sensitive file-related endpoints, especially in administrative interfaces.

How to mitigate directory traversal attacks

Mitigation reduces the damage a traversal bug can cause, but it does not replace fixing the root cause.

Reduce blast radius in custom applications

• Run applications in constrained environments such as containers to limit accessible filesystem scope.
• Segment systems and restrict filesystem permissions so application processes can only read what they need.
• Configure server and platform controls to prevent web applications from reaching parent directories or sensitive paths.

Address traversal in third-party software

• Apply vendor patches and upgrade to non-vulnerable versions as the primary response.
• Track advisories and deploy updates promptly, especially for internet-facing administration interfaces and embedded systems.

Temporary controls

For zero-day issues or when patching is delayed, temporary web application firewall (WAF) rules can help reduce the risk of exploitation. Always treat this as a stopgap that makes known attacks harder, but does not remove the underlying vulnerability or protect you from new attacks against it.

Regular vulnerability scanning helps keep directory traversal bugs out of production

Directory traversal vulnerabilities often slip in through routine features – file download endpoints, export functions, image retrieval, log viewers – especially when code changes quickly and file-handling logic gets reused across services. Regular vulnerability scanning using DAST helps catch traversal issues early by continuously testing the application the way an attacker would, across environments and releases, rather than relying on one-off reviews.

A practical approach is to scan on a schedule and also automatically after meaningful changes, then route verified findings to the right owners with enough detail to fix quickly. If you want to see how this works in practice, a unified platform like Invicti can help you identify and validate exploitable traversal issues as part of your broader web and API security testing workflow. Request a demo to see how automated scanning and validation can fit into your SDLC and release process.