What is Path Traversal Multi-Dot-Slash (CWE-27)? Examples?

TL;DR: CWE-27 is a Path Traversal variant where “../” sequences appear mid-path rather than only as a prefix, which slips past naive prefix-only filters; the fix is full-path canonicalization, not position-specific pattern matching.

What is Path Traversal?

Path Traversal: ‘dir/../../filename’ (CWE-27) is a type of broken access control vulnerability that occurs when an application uses external input to construct a pathname, but fails to neutralize multiple internal “../” sequences that let the resolved path escape a restricted directory. As defined by the MITRE Corporation under CWE-27, this weakness has no official OWASP Top 10:2025 category mapping but is a direct child of Relative Path Traversal (CWE-23).

Quick Summary

This variant matters because of exactly where the dangerous sequence sits in the input, not because the underlying escape mechanism is any different from other path traversal patterns. A validation routine that only checks whether the string starts with “../” will happily pass a value like “dir/../../../etc/passwd” straight through, because the “../” sequences appear after the first path segment rather than at position zero.

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

Path Traversal Overview

What: An application fails to neutralize “../” sequences that appear partway through a constructed pathname, not only at its start.

Why it matters: Validation logic anchored only to the beginning of the input string misses this pattern entirely, giving a false sense of security.

Where it occurs: Any file-path-construction feature that validates input with a prefix-anchored check instead of full canonicalization.

Who is affected: Applications using a naive “does the input start with ../” check rather than resolving and re-verifying the whole path.

Who is NOT affected: Applications that canonicalize the entire resolved path and verify it against the base directory, regardless of where “../” appears in the raw input.

How Path Traversal Works

Root Cause

The application’s validation checks only the start of the input for traversal sequences, missing “../” that appears later in the string.

Attack Flow

1. The attacker identifies a parameter used to build a file path, protected by a prefix-only “../” check.
2. The attacker submits a value like dir/../../../etc/passwd, placing the traversal sequences after the first segment.
3. The prefix check passes because the string doesn’t literally start with “../”.
4. The filesystem still resolves the full path, walking outside the restricted directory.
5. The attacker receives the contents of the unintended file.

Prerequisites to Exploit

• The application validates input with a check anchored only to the start of the string.
• External input reaches a path-building operation without full canonicalization.
• The attacker can place “../” sequences after the first path segment.

Vulnerable Code

def get_file(name):
    base_dir = "/var/app/data"
    if name.startswith(".."):
        raise ValueError("Invalid path")
    path = base_dir + "/" + name
    with open(path) as f:
        return f.read()

The check only rejects input that starts with “..”, so dir/../../../etc/passwd passes straight through and still resolves outside /var/app/data.

Secure Code

import os

def get_file(name):
    base_dir = os.path.abspath("/var/app/data")
    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 every “../” in the input regardless of position, and the check runs against the final resolved path, not the raw string.

Business Impact of Path Traversal

Confidentiality: Attackers may read the contents of unexpected files and expose sensitive data.

Integrity: Attackers may modify files or directories outside the intended restricted directory.

• Exposure of credentials or secrets stored in files outside the intended directory
• False confidence from a validation check that appears to block traversal but does not

Path Traversal Attack Scenario

1. An attacker probes a file-download endpoint and finds that inputs starting with “../” are rejected outright.
2. They instead submit name=docs/../../../etc/passwd, which passes the prefix check.
3. The filesystem resolves the path, walking past the intended docs directory and out to the system root.
4. The attacker receives the password file contents, confirming the prefix-only filter was insufficient.

How to Detect Path Traversal

Manual Testing

• Test traversal sequences both as a prefix and embedded mid-path.
• Confirm whether a prefix-only filter is in use by testing dir/../../target style payloads.
• Verify the actual resolved path server-side, not just whether the request was rejected.

Automated Scanners (SAST / DAST)

Static analysis can flag a prefix-only string check as an incomplete traversal defense, while dynamic testing confirms whether mid-path traversal sequences are actually blocked at runtime.

PenScan Detection

PenScan’s scanner engines submit traversal payloads at multiple positions within the path value, not only as a leading prefix.

False Positive Guidance

A parameter that looks path-like but is always canonicalized and re-verified against the base directory server-side is not vulnerable even if the raw string briefly contains “../” — confirm the final resolved location, not just the input string.

How to Fix Path Traversal

• Canonicalize the full resolved path before any validation, not just the raw input string.
• Verify the canonicalized path against the intended base directory, regardless of where “../” appeared in the input.
• Never validate with a prefix-only or position-specific check for “../”.

Framework-Specific Fixes for Path Traversal

• Java: Paths.get(baseDir, name).normalize() then confirm startsWith(Paths.get(baseDir)).
• Node.js: path.resolve(baseDir, name) then confirm .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).

How to Ask AI to Check Your Code for Path Traversal

Path Traversal Best Practices Checklist

✅ Canonicalize the full resolved path, not just the raw input string ✅ Verify the canonicalized path against the base directory regardless of “../” position ✅ Never use a prefix-only or position-specific traversal check ✅ Test with traversal sequences placed at multiple positions in the input

Path Traversal FAQ

How is CWE-27 different from a single “../” traversal?

CWE-27 specifically covers patterns with multiple internal “../” sequences embedded partway through a path (e.g. “dir/../../filename”), which can slip past filters tuned only to catch a leading “../”.

How does a filter that strips only leading “../” fail here?

A filter checking only the start of the input string never inspects “../” sequences that appear later in the path, so a payload like “dir/../../../etc/passwd” can pass an anchored check while still resolving outside the intended directory.

How dangerous is this compared to standard Relative Path Traversal?

The underlying risk is the same file-exposure impact as CWE-23; the distinguishing factor is purely that naive validation logic is more likely to miss the multi-segment pattern.

How do I detect this pattern during testing?

Test with traversal sequences placed both at the start and in the middle of the path value, not only as a prefix, to confirm the filter catches every position.

How do I fix this correctly?

Canonicalize the full resolved path with realpath() or an equivalent, then verify the result stays inside the intended base directory — this catches every “../” regardless of where it appears in the input.

How does canonicalization avoid needing to find every “../” position?

Canonicalization resolves the entire path in one pass, collapsing every “../” wherever it occurs, so the check happens on the final resolved location instead of trying to pattern-match every possible position in the raw string.

How can PenScan help find this weakness?

PenScan submits multi-segment traversal payloads, not just prefix-anchored ones, against file-related parameters and confirms whether out-of-directory content is returned.

Vulnerabilities Related to Path Traversal

References

• MITRE - CWE-27
• 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 this Path Traversal variant and other risks before an attacker does.