Path Equivalence: '/./' (Single Dot Directory) is a path normalisation trick where '/./' resolves to the same location as '/' but can bypass weak input checks. Attackers use it to evade filters, confuse parsers, or reach restricted files and directories. Defenders should canonicalise paths before validation and compare the resolved path, not the raw string.
How path equivalence works
Path equivalence happens when different-looking path strings resolve to the same filesystem location after normalization. A single dot segment, such as /./, means “current directory,” so it collapses to the same target as / once the path is resolved.
This matters because security checks often fail when they inspect the raw string instead of the canonical path. If validation and file access do not use the same normalization rules, an attacker can present a path that appears different to the filter but identical to the filesystem.
Why /./ can bypass weak checks
Weak input filters sometimes block only exact strings or simple substrings. Because /./ preserves the same destination while changing the textual form, it can defeat blacklist-style checks, confuse parser logic, or slip through code that assumes a path is already normalized.
The underlying problem is not the dot segment itself, but the gap between validation and resolution. When one component compares the raw input and another later resolves the path, the application may make an access decision on one interpretation and execute the file operation on another.
Path equivalence is closely related to canonicalization failures and is often grouped with other path traversal weakness patterns. The CWE Top 25 Guide is a useful reference point for understanding how input-validation weaknesses become exploitable file and directory access issues.
Where this weakness shows up in practice
Applications that accept file paths, upload targets, download paths, archive extraction paths, or routing-style path parameters are the most likely to be affected. The weakness becomes more dangerous when the protected resource sits behind a path-based allowlist, a simple denylist, or a directory prefix check that does not resolve the final destination.
It can also appear in proxies, web frameworks, reverse proxies, and middleware that each normalize paths differently. A request may be transformed more than once before it reaches the final file handler, which creates room for ambiguity and inconsistent enforcement.
Attackers use these differences to reach restricted files, bypass directory boundaries, or trigger unintended handler behavior. In broader terms, it is one of the classic examples of why canonicalization must be part of the trust boundary, not an afterthought.
How defenders prevent and detect it
Defenders should canonicalise the path before making an authorization or safety decision, then compare the resolved path against the intended allowlist or base directory. Validation should operate on the same normalized representation that the file system or application runtime will actually use.
Detection is strongest when logs preserve both the raw request path and the resolved path, because the difference can reveal probing activity or filter evasion attempts. Monitoring should also look for repeated path variants that collapse to the same target, especially when they appear around sensitive files, administrative endpoints, or directory boundaries.
For a broader control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control baseline for access enforcement, input handling, and monitoring, while OWASP API Security Top 10 is helpful where path handling is exposed through APIs and object access logic.
Risk and Threat Considerations
Path equivalence is dangerous because it can turn a simple parsing inconsistency into unauthorized file access. The risk increases when security decisions depend on string matching, especially in applications that expose local file operations or map user input directly into filesystem activity.
Failure mechanism: The attacker supplies a path variant that passes a weak filter, then the application or underlying platform resolves it to a restricted location after the check has already been made.
Impact: The result can be bypassed directory restrictions, unintended file disclosure, access to sensitive configuration, or follow-on compromise if the path leads to a writable or executable location.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Path normalization failures often bypass boundary enforcement checks. |
| SI-10 — Information Input Validation | The issue is a malformed input accepted before safe canonicalization. | |
| Recommendation — Enforce canonical path checks at trust boundaries before allowing file access. Validate normalized paths, not raw strings, before processing. | ||
| OWASP ASVS | V2 — Validation and Business Logic | Path equivalence exploits inconsistent validation and business logic decisions. |
| Recommendation — Apply normalized-path validation before any file or object lookup. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This weakness arises in application input handling and file access logic. |
| Recommendation — Build and test application path handling to resist traversal and equivalence tricks. | ||
| MITRE ATT&CK | T1036 — Masquerading | The attacker changes the apparent form of a path to disguise malicious access. |
| Recommendation — Detect deceptive path variants that conceal restricted-target access. | ||
Practitioner Guidance
Why practitioners should care: Treat path normalization as part of access control, not just input cleanup. If the raw path and the resolved path are not compared consistently, the validation logic is easy to outpace.
What to watch for: Review any code path that uses prefix checks, substring blocking, or custom normalization rules. These are common places where equivalent paths diverge from the developer’s intent.
Practitioner takeaway: The safest pattern is to canonicalise first, validate second, and base the final decision on the resolved path that the application will actually use.
Related resources from NHI Mgmt Group
- Why do hybrid identity environments create more audit and security risk than single-directory setups?
- How should airports govern biometric identity verification without forcing travellers into a single path?
- Why do B2B environments create more identity governance risk than a single enterprise directory?
- Why do fragmented identity systems create more risk than a single directory?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org