CWE-29 is the backslash cousin of the leading slash traversal. The product builds a path from outside input and does not neutralize "..\filename", so the path can leave the directory it was meant to stay in.
MITRE describes it as similar to CWE-25 but using a backslash. Two things make it useful to an attacker. A program may check for ".." only at the start, so a leading backslash slips past. And a protection scheme that assumes "/" is the only separator never considers "" at all.
How it happens
Developers often write and test on one operating system. A filter that strips or rejects "../" feels complete on Linux. Deployed on Windows, where the backslash is the native separator, the same filter misses the attack.
MITRE lists two observed cases. CVE-2002-1987 is a protection mechanism that checks for "/.." but does not account for the Windows specific "..", allowing arbitrary file reads. CVE-2005-2142 is an FTP server where an authenticated attacker could list arbitrary directories with a ".." sequence in an LS command.
What an attacker gains
Reading and modifying files or directories outside the intended root.
How to find it
Static analysis can follow external input to file operations. In testing, repeat every traversal test with backslashes as well as slashes, and with a leading separator.
How to fix it
- Normalize the path with your platform's resolver before any check.
- Compare the resolved path to the allowed base directory.
- Do not rely on a denylist of one separator.
- Prefer identifiers that you map to files yourself.
Quick check
Why test both separators on every platform?
Windows accepts both, and filters written for one often ignore the other. Testing both finds the gap.
