What is Path Equivalence fakedir/../realdir (CWE-57)?

TL;DR: CWE-57 lets an attacker bypass a directory-scoped protection rule by reaching the same target file through a fake-directory-prefix-then-traversal path the rule doesn’t recognize; the fix is canonicalizing the path before the rule is applied.

What is Path Equivalence?

Path Equivalence: ‘fakedir/../realdir/filename’ (CWE-57) is a type of access-control bypass vulnerability that occurs when a protection mechanism restricts access to realdir/filename, but the application also constructs pathnames from external input as fakedir/../realdir/filename, which resolves to the exact same target while never triggering a rule scoped to the realdir prefix. As defined by the MITRE Corporation under CWE-57, this weakness has no official OWASP Top 10:2025 category mapping but is a direct child of Improper Resolution of Path Equivalence (CWE-41).

Quick Summary

This weakness is subtle because the file being reached is often entirely legitimate and would normally be accessible through the correct path — the bypass is purely about which protection mechanism gets triggered, not about escaping to some forbidden location. A rule that only inspects the literal starting directory of a request misses the fact that “../” further along the path walks straight back into the very directory it was supposed to be guarding.

Jump to: Quick Summary · Path Equivalence Overview · How Path Equivalence Works · Business Impact of Path Equivalence · Path Equivalence Attack Scenario · How to Detect Path Equivalence · How to Fix Path Equivalence · Framework-Specific Fixes for Path Equivalence · How to Ask AI to Check Your Code for Path Equivalence · Path Equivalence Best Practices Checklist · Path Equivalence FAQ · Vulnerabilities Related to Path Equivalence · References · Scan Your Own Site

Path Equivalence Overview

What: A protection mechanism scoped to a directory prefix (realdir/) is bypassed by a request path that starts with a different, unprotected prefix (fakedir/) and traverses back to the same real target.

Why it matters: The rule never recognizes the request as targeting the protected directory, even though the resolved file is identical to a directly-requested one.

Where it occurs: Web servers, reverse proxies, or application access rules scoped to a literal directory prefix without resolving “../” first.

Who is affected: Any system where an access rule inspects only the starting segment of a request path rather than its fully resolved form.

Who is NOT affected: Systems that canonicalize the full path before applying any directory-scoped protection rule.

How Path Equivalence Works

Root Cause

A directory-scoped protection mechanism inspects only the literal starting prefix of a request path, without resolving “../” sequences to determine the true final target first.

Attack Flow

1. The attacker identifies a protection mechanism scoped specifically to requests starting with realdir/.
2. The attacker constructs a request starting with a different, unprotected prefix that traverses back into the protected directory, e.g. fakedir/../realdir/filename.
3. The protection mechanism inspects only the literal fakedir prefix and does not apply its rule.
4. The underlying resolver still resolves the path to realdir/filename, and the request succeeds unprotected.

Prerequisites to Exploit

• A protection mechanism is scoped to a specific literal directory prefix.
• The mechanism does not resolve “../” sequences before applying its rule.
• The attacker can construct a request path starting with an unprotected prefix that traverses into the protected one.

Vulnerable Code

app.use("/realdir", requireAuth);
app.use("/", express.static(baseDir));

The authentication middleware is scoped only to requests whose literal path starts with /realdir, so a request for /fakedir/../realdir/secret.txt never matches that prefix rule, while Express’s static file resolution still serves the same file from realdir.

Secure Code

const path = require("path");

app.use((req, res, next) => {
  const resolved = path.normalize(req.path);
  if (resolved.startsWith("/realdir")) {
    return requireAuth(req, res, next);
  }
  next();
});
app.use("/", express.static(baseDir));

The path is normalized (resolving any “../” sequences) before checking the prefix, so a fakedir-prefixed request that resolves into /realdir is correctly recognized and protected.

Business Impact of Path Equivalence

Confidentiality: Attackers may access protected files by routing around a directory-scoped access rule.

Integrity: If the protection mechanism also guards write operations, the same routing bypass could allow unauthorized modification.

• Silent bypass of an access rule that appears correct in configuration but is only checked against the literal prefix
• Exposure of files intended to require authentication or authorization

Path Equivalence Attack Scenario

1. An attacker notices that requests to /realdir/* require authentication, but other paths do not.
2. They request /fakedir/../realdir/confidential.txt instead of /realdir/confidential.txt directly.
3. The authentication middleware, scoped only to the literal /realdir prefix, does not trigger for this request.
4. The static file server still resolves the traversal and serves confidential.txt from the protected directory, unauthenticated.

How to Detect Path Equivalence

Manual Testing

• Identify protection mechanisms scoped to a specific directory prefix.
• Construct requests reaching the same target via a fake-prefix-then-traversal path.
• Confirm whether the protection mechanism is actually applied to the resolved request.

Automated Scanners (SAST / DAST)

Static analysis can flag access rules scoped to a literal path prefix without prior normalization, while dynamic testing confirms whether the live server actually applies protection to a traversal-based request reaching the same target.

PenScan Detection

PenScan’s scanner engines test directory-scoped access rules with fake-prefix traversal paths to confirm whether the intended protection is enforced.

False Positive Guidance

If the protection mechanism (or a layer in front of it) normalizes the path before applying its rule, this specific bypass does not apply — confirm actual request-handling order before treating it as a real finding.

How to Fix Path Equivalence

• Canonicalize the full resolved path before evaluating any directory-scoped protection rule.
• Apply access rules based on the true final target, not the literal starting prefix of the request.
• Ensure any reverse proxy, CDN, or web server layer normalizes paths consistently with the backend application.

Framework-Specific Fixes for Path Equivalence

• Node.js/Express: normalize the path with path.normalize() before applying prefix-based middleware rules, as shown above.
• Java/Spring: ensure Spring Security’s URL pattern matching normalizes the path, and avoid custom prefix checks against the raw request string.
• Python/Django: rely on Django’s URL resolver and view-level decorators rather than manual prefix string matching.
• PHP: normalize the request path with realpath()-equivalent resolution before evaluating any directory-scoped access rule.

How to Ask AI to Check Your Code for Path Equivalence

Path Equivalence Best Practices Checklist

✅ Canonicalize the full resolved path before applying directory-scoped protection rules ✅ Apply access rules to the true final target, not the literal request prefix ✅ Align path normalization across proxy, server, and application layers ✅ Test protected directories with fake-prefix traversal paths during review

Path Equivalence FAQ

How does a “fakedir/../realdir” path bypass a protection mechanism?

If a protection rule is scoped to a specific directory prefix (e.g. only “realdir/” requests are checked), a request like “fakedir/../realdir/filename” resolves to the exact same target file but never matches the rule’s expected prefix, since the literal request path starts with “fakedir”.

How is this different from standard directory-escape Path Traversal?

Standard Path Traversal (CWE-22/23) escapes a restricted directory to reach a location it was never meant to access; CWE-57 reaches the exact same, otherwise-legitimate target file, but does so through a path string that slips past a protection mechanism scoped to a specific literal prefix.

How would this appear in a real deployment?

A web server or reverse-proxy rule that only applies an access check to requests starting with “/realdir/” can be bypassed by a request path like “/fakedir/../realdir/file”, which the backend resolves to “/realdir/file” but which never matched the rule’s prefix check.

How do I detect this in my own application?

For any protection mechanism scoped to a directory prefix, test requests that reach the same target via a fake-directory-then-traversal path and confirm whether the protection is actually applied.

How do I fix this correctly?

Canonicalize the full resolved path before evaluating any directory-scoped protection rule, so the rule is applied to the real, final target rather than the literal, unresolved request string.

How does this affect reverse proxy and CDN configurations specifically?

A reverse proxy or CDN rule keyed to a literal path prefix, without resolving “../” sequences first, can let a fakedir-prefixed request reach the backend’s protected directory while the proxy’s own rule was never triggered.

How can PenScan help find this weakness?

PenScan tests directory-scoped access rules with fake-prefix traversal paths to confirm whether the intended protection is actually enforced.

Vulnerabilities Related to Path Equivalence

References

• MITRE - CWE-57
• 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 Equivalence variant and other risks before an attacker does.