What is Path Traversal Backslash Variant (CWE-28)?

TL;DR: CWE-28 is a Path Traversal variant using backslash “.." sequences instead of forward slashes, which slips past filters written only for “../”; the fix is canonicalization that normalizes all separator styles.

What is Path Traversal?

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

Quick Summary

Many traversal filters are written and tested exclusively against the forward-slash “../” pattern, since that’s the separator most developers think of first. The backslash variant “.." is functionally identical on Windows filesystems and in some cross-platform path-handling libraries, so a filter blind to it leaves the exact same escape route open under a different-looking payload.

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 backslash-based “.." traversal sequences, even if it correctly blocks the forward-slash “../” equivalent.

Why it matters: Backslash is a valid directory separator on Windows and is normalized by several cross-platform libraries, so this isn’t a theoretical edge case.

Where it occurs: File-path-construction features deployed on Windows servers, or using libraries that normalize backslash as a separator regardless of host OS.

Who is affected: Applications that filter only forward-slash traversal sequences and assume backslash is harmless.

Who is NOT affected: Applications that canonicalize the resolved path with a function that normalizes every separator style the platform supports before validating it.

How Path Traversal Works

Root Cause

The application’s traversal filter recognizes only forward-slash “../” sequences and does not account for backslash “.." as an equivalent escape mechanism.

Attack Flow

1. The attacker identifies a parameter used to build a file path, protected by a forward-slash-only traversal filter.
2. The attacker submits a value using backslash sequences, e.g. ..\..\..\windows\win.ini.
3. The filter, written only for “../”, does not recognize the backslash pattern and passes it through.
4. The underlying filesystem or path library resolves the backslash sequence as a directory traversal.
5. The attacker receives the contents of the unintended file.

Prerequisites to Exploit

• The application’s traversal filter checks only for forward-slash sequences.
• The host filesystem or a normalization step in the application treats backslash as a valid separator.
• External input reaches the path-building operation without full canonicalization.

Vulnerable Code

string baseDir = @"C:\App\Data";
string name = Request.QueryString["file"];
if (name.Contains("../"))
{
    throw new ArgumentException("Invalid path");
}
string path = Path.Combine(baseDir, name);

The check only looks for forward-slash “../”, so a value like ..\..\..\Windows\win.ini passes straight through on a Windows host.

Secure Code

string baseDir = Path.GetFullPath(@"C:\App\Data");
string name = Request.QueryString["file"];
string fullPath = Path.GetFullPath(Path.Combine(baseDir, name));
if (!fullPath.StartsWith(baseDir + Path.DirectorySeparatorChar))
{
    throw new ArgumentException("Invalid path");
}

Path.GetFullPath() canonicalizes the resolved path regardless of which separator style was used in the input, and the check runs against that fully-resolved result.

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 configuration files or credentials stored outside the intended directory
• False confidence from a traversal filter that appears complete but only covers one separator style

Path Traversal Attack Scenario

1. An attacker probes a Windows-hosted file-download endpoint and finds forward-slash “../” payloads are rejected.
2. They instead submit file=..\..\..\Windows\win.ini using backslashes.
3. The filter, written only for forward slashes, lets the value through unmodified.
4. The Windows filesystem resolves the backslash sequence as a directory traversal, and the attacker receives the file’s contents.

How to Detect Path Traversal

Manual Testing

• Test file-path parameters with both forward-slash and backslash traversal sequences.
• Confirm the target’s OS or library actually treats backslash as a separator before assuming exploitability.
• Verify the resolved path server-side rather than relying on the raw filter’s rejection message.

Automated Scanners (SAST / DAST)

Static analysis can flag a traversal filter that checks for only one separator style, while dynamic testing confirms whether the live server actually resolves backslash-based traversal at runtime.

PenScan Detection

PenScan’s scanner engines submit both forward-slash and backslash traversal payloads against file-related parameters.

False Positive Guidance

On a purely Unix-hosted application with no path-normalization library that treats backslash specially, a backslash sequence may be inert since the filesystem itself won’t interpret it as a separator — confirm the runtime environment before treating this as a real finding.

How to Fix Path Traversal

• Canonicalize the resolved path with a function that normalizes every separator style the platform recognizes (Path.GetFullPath(), getCanonicalPath(), realpath()).
• Verify the canonicalized path against the intended base directory, not the raw input string.
• Never write a traversal filter that checks for only one separator character.

Framework-Specific Fixes for Path Traversal

• ASP.NET/.NET: Path.GetFullPath() combined with a StartsWith() check against the resolved base directory, as shown above.
• Java: Paths.get(baseDir, name).normalize() then confirm startsWith(Paths.get(baseDir)) — normalizes both separator styles.
• Node.js: path.resolve(baseDir, name) then confirm .startsWith(path.resolve(baseDir)).
• 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 resolved path using a function that normalizes all separator styles ✅ Verify the canonicalized path against the base directory, not the raw input ✅ Never write a traversal filter that checks only one separator character ✅ Test with both forward-slash and backslash payloads during review

Path Traversal FAQ

How is CWE-28 different from standard forward-slash Path Traversal?

CWE-28 specifically covers traversal using the backslash-based “.." sequence instead of the forward-slash “../” sequence, which a filter written only for forward slashes will miss entirely.

How does a Unix-focused filter miss this pattern?

A filter written and tested only against “../” will not recognize “.." as an equivalent traversal sequence, even though Windows filesystems (and some cross-platform libraries) treat backslash as a valid directory separator.

How is this exploitable on a Linux-hosted application?

It is most directly exploitable when the application logic or an underlying library normalizes backslashes to path separators regardless of host OS, or when the application is deployed on Windows where backslash is the native separator.

How do I detect this pattern during testing?

Test file-path parameters with backslash-based traversal sequences (“..\”) in addition to forward-slash ones, especially against applications that might run on or interact with Windows-style paths.

How do I fix this correctly?

Canonicalize the resolved path using a function that normalizes all directory separators the underlying OS or library recognizes, then verify the result against the intended base directory.

How does canonicalization handle both slash styles at once?

A proper canonicalization function (like Java’s getCanonicalPath() or .NET’s GetFullPath()) normalizes whichever separator syntax the platform supports, so both “../” and “.." resolve consistently and can be checked with the same base-directory verification.

How can PenScan help find this weakness?

PenScan submits both forward-slash and backslash traversal payloads against file-related parameters and confirms whether out-of-directory content is returned.

Vulnerabilities Related to Path Traversal

References

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