CWE-35 covers path traversal through the sequence ".../...//". The product builds a pathname from external input and does not neutralize it, so the path can resolve outside the restricted directory.
The interesting part is why the sequence works. It targets filters that remove "../" from input. Remove it once, and what is left behind can be a new "../".
How it happens
Take a filter that deletes every occurrence of "../" in a single pass. Feed it ".../...//" and watch what survives. Cutting the inner "../" pieces leaves characters that join up to form "../" again. MITRE calls this a collapse into an unsafe value, tracked as CWE-182.
The filter did its job on the input it saw, and the result was still dangerous. Single pass sanitizing is the weakness here, not the sequence itself.
What an attacker gains
MITRE lists reading files or directories, modifying them, and bypassing a protection mechanism. Two observed cases show the pattern. CVE-2005-2169 is a chain where ".../...//" beat regular expressions that remove "../". CVE-2005-0202 is a variant, ".../....///", that bypassed expressions removing "./" and "../".
How to find it
Static analysis can flag file operations fed by external input. Design review helps too: any code that cleans paths by deleting substrings is a candidate. Test with nested and repeated sequences, not just the plain one.
How to fix it
- Stop sanitizing by removal. Reject suspicious input instead.
- Resolve the final path and compare it to the allowed base directory.
- If you must filter, loop until the value stops changing, then still verify the resolved path.
- Map user choices to server side file names.
Quick check
Why does removing a sequence once fail?
The removal can join the surrounding characters into a new copy of the sequence. Checking the resolved path avoids the problem.
