What is Path Traversal Multiple Dot (CWE-33)?

TL;DR: CWE-33 is a Path Traversal variant using “….” (multiple-dot) sequences that some parsers resolve the same as “..”, bypassing filters tuned only for the exact two-dot pattern; the fix is full-path canonicalization.

What is Path Traversal?

Path Traversal: ‘….’ (Multiple Dot) (CWE-33) 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 dot) sequences that some path parsers resolve identically to a standard “../” traversal. As defined by the MITRE Corporation under CWE-33, 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 exists because some path-normalization implementations treat any run of more than two dots as equivalent to “..”, collapsing “….” down to the same traversal effect. A filter that was written to reject exactly the two-character string “..” — and nothing else — can miss this longer variant entirely, even though the underlying resolution behaves the same way.

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 of more than two dots, which some parsers resolve identically to standard “..” traversal.

Why it matters: A filter tuned to reject only the exact two-dot pattern gives a false sense of completeness if the underlying parser treats longer dot runs the same way.

Where it occurs: File-path-construction features relying on a parser or library with non-standard dot-run normalization behavior.

Who is affected: Applications validating against an exact “..” string match rather than canonicalizing the resolved path.

Who is NOT affected: Applications that canonicalize the full resolved path and verify it against the base directory, regardless of the dot pattern used in the input.

How Path Traversal Works

Root Cause

The application’s traversal filter checks for the literal “..” string and does not account for longer dot-run sequences that some parsers normalize the same way.

Attack Flow

1. The attacker identifies a parameter used to build a file path, protected by a filter that rejects exactly “..”.
2. The attacker submits a value using a longer dot sequence, e.g. ..../..../etc/passwd.
3. The filter, matching only the exact two-dot string, does not flag the longer sequence.
4. The underlying path parser normalizes the multi-dot sequence the same way it would “..” and resolves outside the restricted directory.
5. The attacker receives the contents of the unintended file.

Prerequisites to Exploit

• The application’s filter checks for an exact two-dot pattern rather than canonicalizing the path.
• The underlying path-resolution library or OS normalizes longer dot runs equivalently to “..”.
• External input reaches the path-building operation without full canonicalization.

Vulnerable Code

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

Checking for the literal ".." substring still catches a straightforward attempt, but a parser-level normalization quirk that treats a longer run of dots equivalently would bypass an exact-match implementation of this same idea.

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 the path according to the same normalization rules the OS uses, so the base-directory check is validated against the true final location regardless of the dot pattern in the raw input.

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 configuration data stored outside the intended directory
• False confidence from a dot-pattern filter that appears complete but isn’t

Path Traversal Attack Scenario

1. An attacker probes a file-download endpoint and finds standard “../” payloads are rejected by an exact-match filter.
2. They try a payload using extended dot sequences instead of the standard pattern.
3. The filter, tuned only to the standard two-dot string, does not recognize the variant.
4. The underlying path resolution still walks outside the restricted directory, and the attacker receives the file’s contents.

How to Detect Path Traversal

Manual Testing

• Test file-path parameters with both the standard two-dot traversal and longer dot-run variants.
• Confirm whether the target’s path-parsing library normalizes longer dot runs equivalently to “..”.
• Verify the actual resolved path server-side rather than relying on the filter’s rejection message alone.

Automated Scanners (SAST / DAST)

Static analysis can flag an exact-match traversal filter as an incomplete defense, while dynamic testing confirms whether the live server actually resolves multi-dot sequences as traversal at runtime.

PenScan Detection

PenScan’s scanner engines submit multi-dot traversal payloads alongside standard patterns against file-related parameters.

False Positive Guidance

If the application’s underlying platform and libraries are confirmed not to normalize longer dot runs as traversal, this specific variant may not be exploitable even if the general pattern is flagged — confirm actual parser behavior before treating it as a real finding.

How to Fix Path Traversal

• Canonicalize the resolved path with a real path-resolution function instead of pattern-matching specific dot sequences.
• Verify the canonicalized path against the intended base directory.
• Never rely on an exact-match or substring filter for a specific traversal pattern as the sole defense.

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 instead of matching specific dot patterns ✅ Verify the canonicalized path against the base directory ✅ Never rely solely on an exact-match filter for “..” or similar patterns ✅ Test with extended dot-run payloads, not just the standard two-dot sequence

Path Traversal FAQ

How does a “….” sequence cause path traversal?

Some path-parsing implementations collapse a run of more than two dots into a “..” traversal sequence during normalization, so “….” can resolve the same way “../..” would even though a filter looking only for the literal two-dot pattern never flags it.

How is this different from standard Relative Path Traversal (CWE-23)?

CWE-23 covers the literal “..” sequence; CWE-33 covers the case where a filter blocks exactly “..” but a longer run of dots like “….” still resolves as a traversal due to how the underlying parser normalizes it.

How would a filter miss “….” if it already blocks “..”?

A filter using an exact-match or simple substring check for “..” specifically may not recognize a four-dot sequence as the same pattern, especially if the check was written expecting exactly two dots.

How do I detect this pattern during testing?

Test file-path parameters with sequences of three, four, or more dots in addition to the standard two-dot payload, since some parsers treat runs of dots equivalently to “..”.

How do I fix this correctly?

Canonicalize the resolved path with a real path-resolution function rather than pattern-matching for specific dot sequences, then verify the result against the intended base directory.

How does canonicalization avoid this entire class of dot-sequence bypass?

A canonicalization function resolves the path according to the same rules the filesystem itself uses, so however many dots are present, the check happens on the actual final location rather than on the raw dot pattern.

How can PenScan help find this weakness?

PenScan submits traversal payloads using multiple-dot sequences, not just the standard two-dot pattern, against file-related parameters.

Vulnerabilities Related to Path Traversal

References

• MITRE - CWE-33
• 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.