What causes path equivalence: ‘/./’ (single dot directory)?

Why '/./' Resolves to the Same Path

The sequence /./ contains the single dot directory, which means “current directory.” Because it does not move the path anywhere, normal path resolution collapses it to the same location as /. The important point is that this is a filesystem normalization rule, not a special access path.

That equivalence becomes security-relevant when software compares raw strings instead of canonicalised paths. A request that looks different on the surface can still point to the same resource after normalisation, which is why string-based checks are easy to bypass.

How Attackers Abuse Path Equivalence

Attackers use /./ to make a blocked or constrained path appear harmless to filters, routing rules, or allow lists that do not resolve the path first. This is the same class of problem as path equivalence weaknesses more broadly: the application reasons over the text, while the operating system reasons over the normalised path.

It also overlaps with other canonicalisation failures such as alternate-name handling and incomplete mediation. If the security decision happens before path normalisation, an attacker can sometimes reach a protected file, endpoint, or directory through a syntactic variation that the defender did not anticipate.

What Defenders Should Validate Before Trusting a Path

Defensive logic should compare canonicalised paths, not user-supplied strings. In practice that means resolving dot segments, redundant separators, encoding variations, and platform-specific quirks before you decide whether the request is allowed.

That control is only effective if the exact same normalisation rules are used consistently across validation, authorisation, logging, and downstream file access. If one component validates the raw path and another component later resolves it, the application can create a mismatch that attackers exploit.

For path-based controls, the safest pattern is to normalise first, then apply policy, then access the resource through the already-resolved form. That reduces the chance that a security rule, cache entry, or audit record refers to one path while the filesystem actually serves another.

Risk and Threat Considerations

Path equivalence flaws matter because they let untrusted input influence access control decisions through syntax rather than content. The result is often a bypass of file restrictions, directory boundaries, or content filters without needing a complex exploit chain.

Failure mechanism: The application evaluates the raw path string before canonicalisation, so a request containing /./ can evade a comparison that was intended to block the resolved target path.

Impact: An attacker may reach files, directories, or handlers that were meant to be hidden, restricted, or denied, which can expose data or enable follow-on abuse of the application’s file handling logic.

Practitioner Guidance

What to verify: Confirm that the security gate uses the same canonical form that the runtime or filesystem uses, and test cases that include dot segments, redundant slashes, and mixed encoding. If the pre-check and the actual access path differ, the control is not trustworthy.

Common mistake: Treating a deny rule on the literal string as equivalent to denying the resolved resource. That assumption fails as soon as the platform normalises the path after the check.

Practitioner takeaway: The key decision is not whether /./ looks unusual, it is whether every access decision is made after path normalisation and on the same canonical form end to end.

Related resources from NHI Mgmt Group

• Path Equivalence: '/./' (Single Dot Directory)
• 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?