What is Relative Path Traversal (CWE-23)?

TL;DR: Relative Path Traversal lets an attacker use “..” sequences to escape a restricted directory; the fix is canonicalizing the path and verifying it stays inside the intended base directory, never a substring filter on “..”.

What is Relative Path Traversal?

Relative Path Traversal (CWE-23) is a type of broken access control vulnerability that occurs when an application uses external input to construct a pathname intended to stay inside a restricted directory, but does not properly neutralize “..” sequences that let the resolved path escape it. As defined by the MITRE Corporation under CWE-23, and classified by the OWASP Foundation under A01:2025 - Broken Access Control, this is a specific, well-documented child of the broader Path Traversal (CWE-22) weakness family.

Quick Summary

The “..” sequence is one of the oldest and most reliable ways to escape a restricted directory, because most filesystems treat it as a literal “go up one level” instruction with no awareness of any application-level restriction layered on top. Any endpoint that builds a file path from user input without canonicalizing and re-checking it is a candidate for this exact attack.

Jump to: Quick Summary · Relative Path Traversal Overview · How Relative Path Traversal Works · Business Impact of Relative Path Traversal · Relative Path Traversal Attack Scenario · How to Detect Relative Path Traversal · How to Fix Relative Path Traversal · Framework-Specific Fixes for Relative Path Traversal · How to Ask AI to Check Your Code for Relative Path Traversal · Relative Path Traversal Best Practices Checklist · Relative Path Traversal FAQ · Vulnerabilities Related to Relative Path Traversal · References · Scan Your Own Site

Relative Path Traversal Overview

What: An application builds a file path from external input and fails to neutralize “..” sequences that let the path resolve outside its intended base directory.

Why it matters: “..” is interpreted by the filesystem itself, not the application, so it bypasses any directory restriction that isn’t explicitly re-verified after path resolution.

Where it occurs: File-download, file-include, and archive-extraction features that build paths from user-supplied filenames.

Who is affected: Applications that concatenate user input into a path without canonicalizing and re-checking the result.

Who is NOT affected: Applications already canonicalizing every constructed path and verifying it stays inside the intended base directory before use.

How Relative Path Traversal Works

Root Cause

The application does not neutralize “..” sequences in externally-supplied input before using it to build a filesystem path.

Attack Flow

1. The attacker locates a parameter used to build a file path.
2. The attacker submits a value containing repeated “../” sequences targeting a file outside the restricted directory.
3. The filesystem resolves the path literally, walking up past the intended base directory.
4. The application performs its file operation against the unintended target.
5. The attacker receives the contents of a file it was never meant to expose.

Prerequisites to Exploit

• External input reaches a path-building operation.
• The application does not canonicalize the resolved path.
• The application does not verify the canonicalized path is still inside the intended base directory.

Vulnerable Code

import os

def get_file(name):
    base_dir = "/var/app/uploads"
    path = base_dir + "/" + name
    with open(path) as f:
        return f.read()

name is concatenated directly with no validation, so ../../../../etc/passwd resolves straight out of /var/app/uploads.

Secure Code

import os

def get_file(name):
    base_dir = os.path.abspath("/var/app/uploads")
    full_path = os.path.abspath(os.path.join(base_dir, name))
    if not full_path.startswith(base_dir + os.sep):
        raise ValueError("Invalid path")
    with open(full_path) as f:
        return f.read()

os.path.abspath() resolves any “..” sequences first, and the explicit startswith() check rejects any result that lands outside the real base directory.

Business Impact of Relative Path Traversal

Confidentiality: Attackers may read the contents of unexpected files and expose sensitive data by traversing the file system.

Integrity: Attackers may overwrite or create critical files, such as programs or important configuration data.

Availability: Attackers may overwrite, delete, or corrupt critical files, preventing the application from working at all.

• Direct exposure of credentials or secrets stored outside the intended directory
• Potential lockout of legitimate users if critical files are overwritten
• Loss of customer trust following any confirmed data exposure incident

Relative Path Traversal Attack Scenario

1. An attacker finds a document-viewer endpoint that accepts a name parameter for the file to display.
2. They submit name=../../../../etc/passwd and the response returns the system password file contents.
3. Encouraged, they target name=../../config/secrets.yml and retrieve API keys stored there.
4. Those keys are then used to access other systems well beyond the original file viewer’s scope.

How to Detect Relative Path Traversal

Manual Testing

• Identify every parameter that feeds into a file path.
• Submit chained “../” sequences and their URL-encoded equivalents against each.
• Confirm whether responses return content from outside the expected directory.
• Test with varying traversal depths to confirm the boundary is real, not accidental.

Automated Scanners (SAST / DAST)

Static analysis can flag string concatenation into file operations directly in source, while dynamic testing confirms whether the live server actually honors traversal sequences at runtime.

PenScan Detection

PenScan’s scanner engines submit real “../” payloads, including encoded variants, against file parameters and confirm whether out-of-directory content is returned.

False Positive Guidance

If the application already canonicalizes and validates the path but a scanner still flags the parameter purely based on its name, manually confirm the actual resolved path before treating it as a real finding.

How to Fix Relative Path Traversal

• Canonicalize the resolved path with realpath(), getCanonicalPath(), or the platform equivalent before any use.
• Explicitly verify the canonicalized path still starts with the intended base directory.
• Never rely on stripping or replacing “../” as a standalone fix — encoding and repeated substitution can bypass it.
• Prefer mapping user-supplied identifiers to fixed filenames server-side instead of accepting raw paths.

Framework-Specific Fixes for Relative Path Traversal

• Java: Paths.get(baseDir, name).normalize() then confirm startsWith(Paths.get(baseDir)).
• Node.js: path.resolve(baseDir, name) then confirm the result .startsWith(path.resolve(baseDir)).
• Python/Django: os.path.abspath(os.path.join(baseDir, name)) with a startswith() check, as shown above.
• PHP: realpath() on the constructed path, checked against realpath($baseDir) before any file access.

How to Ask AI to Check Your Code for Relative Path Traversal

Relative Path Traversal Best Practices Checklist

✅ Canonicalize every constructed path before use ✅ Explicitly verify the canonicalized path stays inside the intended directory ✅ Never rely on stripping “..” as the sole defense ✅ Prefer ID-to-fixed-filename mapping over raw user-supplied paths ✅ Test with encoded and repeated traversal sequences, not just plain “../”

Relative Path Traversal FAQ

How does the “../” sequence let an attacker escape a directory?

Each “../” moves the resolved path one directory level up; enough of them chained together walk the path out of the restricted base directory entirely and onto the rest of the filesystem.

How is Relative Path Traversal different from CWE-22?

CWE-22 is the general parent weakness for any pathname escaping a restricted directory; CWE-23 is specifically the case where that escape is achieved with relative “..” sequences.

How many “../” sequences does an attacker typically need?

Enough to walk from the application’s restricted directory up to the filesystem root, which depends entirely on how deep that directory is nested — attackers commonly send several repetitions to be safe.

How do encoding tricks bypass a naive “../” filter?

URL-encoding (“%2e%2e%2f”), double-encoding, or mixing separators can all produce a traversal sequence that a simple string-replace filter never recognizes as “../” in its raw form.

How do I detect this in my own application?

Submit “../” sequences (and their encoded variants) in every parameter that feeds a file path, and confirm whether the response returns content from outside the intended directory.

How do I fix Relative Path Traversal correctly?

Canonicalize the resolved path with a function like realpath(), then explicitly verify it still starts with the intended base directory before using it — never strip “../” with a substring replace.

How can PenScan help find this weakness?

PenScan sends real “../” traversal payloads, including encoded variants, against file-related parameters and confirms whether out-of-directory content is returned.

Vulnerabilities Related to Relative Path Traversal

References

• MITRE - CWE-23
• OWASP A01:2025 - Broken Access Control
• NVD

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Relative Path Traversal and other risks before an attacker does.