CWE-30 describes path traversal through sequences shaped like "\dir..\filename". The product builds a path from external input and does not neutralize the embedded backslash dot-dot, so the final path lands outside the restricted directory.
MITRE says it is similar to CWE-26, with a backslash in place of a slash. The manipulation helps bypass some protection schemes. Sometimes a program only checks for ".." at the beginning of the input, so a path that begins with a directory name and climbs afterward goes unnoticed.
How it happens
Imagine input is rejected if it starts with "..". The attacker supplies "\dir..\filename". The text starts with a separator and a normal looking directory name, so the check passes. When the operating system resolves the path, "dir" is entered and immediately left, which collapses to a plain filename in the parent. Add more climbing and the path escapes the base entirely.
The core error is judging safety from the shape of the string rather than from the path it resolves to.
What an attacker gains
MITRE lists reading files or directories and modifying files or directories. The observed example is CVE-2002-1987, where a protection mechanism checked for "/.." but did not account for the Windows specific "..", allowing reads of arbitrary files.
How to find it
Static analysis that traces external input into file calls can flag these. During testing, try the shape directly: a directory, a climb, then a target filename, with both separators.
How to fix it
- Resolve the full path with the platform resolver first.
- Confirm the resolved path starts with the permitted base directory.
- Reject input that contains separators when you only expect a bare filename.
- Run the service with the least file system access it needs.
Quick check
Why does the embedded form defeat a start-of-string check?
The dangerous sequence is not at the start, so the check never sees it. Only the resolved path reveals the escape.
