CWE-161 describes input with several special elements in a row at the start, handled in a way the author did not expect. The textbook case is repeated slashes at the front of a URL path.
Web servers, routers and any access rule that matches on a path string are affected. If your rule says deny a path and compares text, repeated characters can change whether it matches.
How it happens
The check expects one slash. The file system or the next layer treats many slashes as one. The two sides disagree.
The record's example is CVE-2002-1238, where a server allows remote attackers to bypass access restrictions for files with an HTTP request containing a sequence of multiple slash characters, like three slashes before the file name.
What an attacker gains
MITRE lists integrity impact as unexpected state. The observed result was access to files that restrictions were meant to protect.
How to find it
No detection methods are listed. Send paths with doubled, tripled and longer slash runs against every protected route. Compare the response to the normal path. If they differ, a rule is matching raw text.
How to fix it
- Anticipate that multiple leading special elements will be injected or manipulated.
- Normalize the path first: collapse repeated separators and resolve dot segments. Then apply access rules to the normalized form only.
- Use an allowlist of valid routes instead of a list of blocked ones.
- Make sure the layer that enforces access sees the same string as the layer that serves the file.
Quick check
Why not just block triple slashes?
A denylist of one pattern misses the next variant. Normalize, then match.
