What is Path Equivalence Trailing Dot (CWE-42)?

TL;DR: CWE-42 lets an attacker bypass a filename-based access check by appending a trailing dot, which Windows silently strips when resolving the file; the fix is canonicalizing the filename before comparison.

What is Path Equivalence?

Path Equivalence: Trailing Dot (CWE-42) is a type of access-control bypass vulnerability that occurs when an application accepts a filename with a trailing dot without recognizing that it resolves to the same underlying file as the name without it. As defined by the MITRE Corporation under CWE-42, this weakness has no official OWASP Top 10:2025 category mapping but is a direct child of Improper Resolution of Path Equivalence (CWE-41) and Improper Neutralization of Trailing Special Elements (CWE-162).

Quick Summary

Windows has historically stripped trailing dots from filenames during path resolution, a legacy compatibility behavior most application developers don’t know about. That mismatch between how an application’s string comparison sees a filename and how the OS actually resolves it is exactly what this weakness exploits — the check and the filesystem simply disagree.

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 ending in a trailing dot resolves to the same file as the name without the dot, but a string-comparison-based access check treats them as different values.

Why it matters: Any access control, extension filter, or blocklist implemented as a raw string comparison can be silently bypassed by this one-character difference.

Where it occurs: Windows-hosted applications performing filename-based access checks or extension filtering by direct string comparison.

Who is affected: Applications that compare filenames as literal strings before a Windows file API resolves them.

Who is NOT affected: Applications that canonicalize the filename via the OS’s own resolution function before comparing it against any access rule.

How Path Equivalence Works

Root Cause

The application’s access check compares the raw filename string, without accounting for Windows silently stripping a trailing dot during actual path resolution.

Attack Flow

1. The attacker identifies a filename-based access check or extension filter (e.g. blocking direct requests for config.php).
2. The attacker appends a trailing dot to the requested filename, e.g. config.php..
3. The string-comparison check sees a different value than the blocked one and allows the request.
4. Windows resolves the trailing-dot 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 application runs on Windows, where trailing dots are stripped during path resolution.
• The attacker can control or influence the requested filename.

Vulnerable Code

string requested = Request.QueryString["file"];
if (requested == "config.php")
{
    throw new UnauthorizedAccessException();
}
string content = File.ReadAllText(Path.Combine(baseDir, requested));

The check only blocks the exact string "config.php", so a request for "config.php." passes the comparison while Windows still resolves it to the same protected file.

Secure Code

string requested = Request.QueryString["file"];
string canonicalName = Path.GetFileName(Path.GetFullPath(Path.Combine(baseDir, requested)));
if (canonicalName.Equals("config.php", StringComparison.OrdinalIgnoreCase))
{
    throw new UnauthorizedAccessException();
}
string content = File.ReadAllText(Path.Combine(baseDir, canonicalName));

Path.GetFullPath() resolves the filename the same way Windows itself will, so the trailing dot is already stripped before the comparison runs, closing the bypass.

Business Impact of Path Equivalence

Access Control: A trailing-dot request bypasses any filename-based access rule implemented as a raw string comparison, exposing whatever that rule was meant to protect.

• Exposure of configuration files or other resources an application specifically tried to block
• False confidence in an access control that appears correct in code review but is bypassable at runtime

Path Equivalence Attack Scenario

1. An attacker notices a web application explicitly blocks direct requests for config.php.
2. They instead request config.php. (with a trailing dot).
3. The application’s exact-match check does not recognize this as the blocked filename and serves the request.
4. Windows resolves the trailing-dot filename to the same config.php, and its contents are returned to the attacker.

How to Detect Path Equivalence

Manual Testing

• Identify filename-based access checks or extension filters implemented as string comparisons.
• Append a trailing dot to a value that should be blocked and confirm whether it is still served.
• Repeat for any other filename normalization the application relies on.

Automated Scanners (SAST / DAST)

Static analysis can flag filename comparisons using simple string equality, while dynamic testing confirms whether a Windows-hosted target actually resolves a trailing-dot variant to the blocked resource.

PenScan Detection

PenScan’s scanner engines test filename-based access controls with a trailing-dot variant to confirm whether blocked resources remain reachable.

False Positive Guidance

On non-Windows deployments, a trailing dot is typically treated as a literal character and does not cause equivalence, so this specific bypass may not be exploitable outside a Windows-hosted target — confirm the runtime OS before treating it as a real finding.

How to Fix Path Equivalence

• Canonicalize the filename with the OS’s own path-resolution function before any access-control comparison.
• Never implement filename-based access rules as a raw string equality check alone.
• Prefer allowlisting known-good filenames over blocklisting specific dangerous ones.

Framework-Specific Fixes for Path Equivalence

This weakness is specific to Windows filename resolution behavior; it has no equivalent bypass mechanism on Linux/macOS filesystems, so no forced-fit examples are given for those platforms.

• ASP.NET/.NET: canonicalize with Path.GetFullPath() and Path.GetFileName() before any comparison, as shown above.
• Java on Windows: use Paths.get(input).toRealPath() (when the file exists) or .normalize() to resolve the canonical filename before comparing it against any blocklist.

How to Ask AI to Check Your Code for Path Equivalence

Path Equivalence Best Practices Checklist

✅ Canonicalize filenames with the OS’s own resolution function before any comparison ✅ Never rely on raw string equality for filename-based access control ✅ Prefer allowlisting known-good filenames over blocklisting specific ones ✅ Test blocked resources with a trailing-dot variant during review

Path Equivalence FAQ

How does a trailing dot bypass a filename-based check?

Windows silently strips a trailing dot from a filename when resolving it, so “secret.txt.” and “secret.txt” open the exact same file even though they are different strings — an access check comparing the raw string sees two different values.

How is Path Equivalence different from Path Traversal?

Path Traversal (CWE-22/23) escapes a restricted directory entirely; Path Equivalence stays inside the same directory but exploits an OS-level quirk that makes two differently-formatted filenames resolve to the same file, bypassing a check that only compares the literal string.

How would an attacker actually use this in practice?

If an application blocks direct access to a specific filename (e.g. a config file) by comparing the requested name exactly, appending a trailing dot to the request can still resolve to that same blocked file while passing the string comparison.

How do I detect this in my own application?

Test any filename-based access check by appending a trailing dot to a value that should be blocked, and confirm whether the underlying file is still served.

How do I fix this correctly?

Canonicalize the filename with the OS’s own path-resolution function before running any access check, so the comparison happens on the resolved name Windows will actually use, not the raw input string.

How does canonicalization prevent every equivalence trick, not just trailing dots?

A canonicalization function applies the same normalization rules the filesystem itself uses, so trailing dots, trailing spaces, and other OS-specific equivalence quirks are all resolved to one consistent form before any comparison happens.

How can PenScan help find this weakness?

PenScan tests filename-based access controls with trailing-dot and other path-equivalence variants to confirm whether blocked resources are still reachable.

Vulnerabilities Related to Path Equivalence

References

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