What is Path Equivalence Internal Whitespace (CWE-48)?

TL;DR: CWE-48 lets an attacker bypass a filename-based access check using internal whitespace variants that some parsers normalize equivalently; the fix is canonicalizing the filename before comparison, or allowlisting exact known-good names.

What is Path Equivalence?

Path Equivalence: Internal Whitespace (CWE-48) is a type of access-control bypass vulnerability that occurs when an application accepts a filename containing internal whitespace without recognizing that it may resolve to the same underlying file as a differently-spaced variant. As defined by the MITRE Corporation under CWE-48, 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 is the “space in the middle of the filename” sibling of the trailing-dot and trailing-space equivalence weaknesses — the exact normalization behavior varies more by platform and library than the trailing-character variants do, which makes it easy for a developer to assume a filename check is exhaustive when it isn’t.

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 filename containing internal whitespace can resolve to the same underlying file as a differently-spaced variant, depending on platform/library normalization behavior.

Why it matters: A filename-based access check comparing the raw string can be defeated by any whitespace variant the resolver treats as equivalent.

Where it occurs: Applications performing filename-based access checks by direct string comparison, on platforms or libraries with non-obvious whitespace normalization.

Who is affected: Applications that compare filenames as literal strings without canonicalizing them first.

Who is NOT affected: Applications that canonicalize the filename via the platform’s own resolution function, or that use an allowlist of exact known-good filenames.

How Path Equivalence Works

Root Cause

The application’s access check compares the raw filename string without accounting for whitespace-normalization behavior in the underlying filesystem or parsing library.

Attack Flow

1. The attacker identifies a filename-based access check (e.g. blocking direct requests for a specific protected file).
2. The attacker submits a whitespace-variant of that filename that the underlying resolver treats as equivalent.
3. The string-comparison check sees a different value than the blocked one and allows the request.
4. The filesystem or library resolves the whitespace-variant filename to the same underlying file, serving the blocked content anyway.

Prerequisites to Exploit

• The application performs a filename-based access check via direct string comparison.
• The underlying filesystem or parsing library normalizes some internal whitespace variant equivalently.
• The attacker can control or influence the requested filename.

Vulnerable Code

def get_file(name):
    if name == "internal report.pdf":
        raise PermissionError("Access denied")
    return open(os.path.join(base_dir, name)).read()

The check blocks only the exact string "internal report.pdf", so any whitespace variant the underlying filesystem treats as equivalent bypasses the comparison while still resolving to the same protected file.

Secure Code

import os

ALLOWED_FILES = {"quarterly-report.pdf", "readme.txt"}

def get_file(name):
    if name not in ALLOWED_FILES:
        raise PermissionError("Access denied")
    return open(os.path.join(base_dir, name)).read()

Rather than trying to enumerate every whitespace-equivalence variant of a blocked filename, this allowlists the specific, exact filenames that are permitted — any variant of anything else is rejected by construction.

Business Impact of Path Equivalence

Access Control: Attackers may access files that a raw string-based access check was meant to protect, by exploiting how internal whitespace is normalized.

• Exposure of specific files an application tried to block by exact filename comparison
• False confidence in a blocklist-style access check that appears complete but isn’t

Path Equivalence Attack Scenario

1. An attacker notices a document-viewer application explicitly blocks direct requests for internal report.pdf.
2. They discover the underlying storage layer normalizes a whitespace variant of that name to the same file.
3. They request the whitespace-variant name, which passes the application’s exact-match check.
4. The storage layer resolves it to the same protected file, and its contents are returned to the attacker.

How to Detect Path Equivalence

Manual Testing

• Identify filename-based access checks implemented as string comparisons.
• Test whitespace variants (added, removed, or repeated internal spaces) of a value that should be blocked.
• Confirm whether the underlying storage layer treats any variant as equivalent to the blocked name.

Automated Scanners (SAST / DAST)

Static analysis can flag filename comparisons using simple string equality, while dynamic testing confirms whether the live storage layer actually normalizes any whitespace variant to the blocked resource.

PenScan Detection

PenScan’s scanner engines test filename-based access controls with internal-whitespace variants to confirm whether blocked resources remain reachable.

False Positive Guidance

If the underlying filesystem or library does not normalize internal whitespace at all, this specific bypass is not exploitable even if a scanner flags the parameter based on its name — confirm actual resolver behavior before treating it as a real finding.

How to Fix Path Equivalence

• Canonicalize the filename with the platform’s own resolution function before any access-control comparison.
• Prefer an allowlist of exact, known-good filenames over a blocklist of specific bad ones.
• Never assume a raw string comparison is exhaustive against every whitespace variant a resolver might normalize.

Framework-Specific Fixes for Path Equivalence

• Java: normalize the filename with Paths.get(name).normalize().toString() before comparison, or prefer an allowlist as shown above.
• Node.js: normalize with path.normalize() before any comparison, or map user-facing identifiers to fixed filenames server-side.
• Python/Django: canonicalize with os.path.normpath(), or use an explicit allowlist set as shown above.
• PHP: normalize with a consistent whitespace-collapsing step before comparison, or maintain an allowlist array of permitted filenames.

How to Ask AI to Check Your Code for Path Equivalence

Path Equivalence Best Practices Checklist

✅ Canonicalize filenames before any access-control comparison ✅ Prefer an allowlist of exact known-good filenames over a blocklist ✅ Never assume a raw string comparison covers every whitespace-normalization variant ✅ Test blocked resources with internal-whitespace variants during review

Path Equivalence FAQ

How does internal whitespace in a filename cause an equivalence bypass?

Some filesystems or parsing libraries normalize or ignore certain internal whitespace when resolving a filename, so “file name” and “filename” (or other spacing variants) can resolve to the same underlying resource even though a raw string comparison treats them as different.

How is this different from Path Equivalence Trailing Space (CWE-46)?

CWE-46 covers whitespace appended at the end of a filename; CWE-48 covers whitespace embedded in the middle of the filename itself, which is a separate normalization behavior with its own edge cases.

How would an attacker actually exploit this?

If an access check or extension filter blocks a specific filename by exact string match, inserting or removing internal whitespace at a position the underlying resolver ignores can produce a request that passes the filter while still reaching the same protected file.

How do I detect this in my own application?

Test filename-based access checks with variants that add or remove internal whitespace and confirm whether the underlying resource is still reachable under each variant.

How do I fix this correctly?

Canonicalize the filename with the platform’s own resolution function before running any access check, so whatever whitespace-normalization behavior exists is already accounted for at comparison time.

How does an allowlist help beyond canonicalization alone?

An allowlist of exact, known-good filenames (rather than a blocklist of specific bad ones) sidesteps the whole equivalence question, since only pre-approved values are ever served regardless of how whitespace is normalized.

How can PenScan help find this weakness?

PenScan tests filename-based access controls with internal-whitespace variants to confirm whether blocked resources are still reachable.

Vulnerabilities Related to Path Equivalence

References

• MITRE - CWE-48
• 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.