What is Path Equivalence Multiple Slash (CWE-51)?

TL;DR: CWE-51 lets an attacker bypass a path-based access rule by inserting doubled internal slashes that the resolver collapses to the intended path anyway; the fix is normalizing the path before the rule is evaluated.

What is Path Equivalence?

Path Equivalence: Multiple Internal Slash (CWE-51) is a type of access-control bypass vulnerability that occurs when an application accepts a path containing repeated internal slashes without recognizing that it resolves to the same underlying resource as the single-slash form. As defined by the MITRE Corporation under CWE-51, 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

Repeated slashes in a path are silently collapsed by nearly every web server and filesystem — “/a//b” and “/a/b” are the same resource everywhere that matters at runtime. An access rule that compares the raw request string, rather than the normalized path, disagrees with the server it’s protecting, and that disagreement is exactly the bypass.

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 path containing repeated internal slashes resolves to the same resource as the collapsed single-slash form, but a rule comparing the raw string treats them as different values.

Why it matters: Any access control, WAF rule, or filter implemented as an exact path-string match can be bypassed by this trivial normalization gap.

Where it occurs: Web servers, application routers, and access-control middleware that don’t normalize the path before comparison.

Who is affected: Applications enforcing path-based rules via exact string matching rather than after path normalization.

Who is NOT affected: Applications that normalize repeated slashes consistently before evaluating any access rule.

How Path Equivalence Works

Root Cause

The application (or a layer protecting it) resolves repeated internal slashes to the same route as the single-slash form, while an access rule is evaluated against the raw, un-normalized string.

Attack Flow

1. The attacker identifies a path-based access rule blocking a specific route, e.g. /admin/secret.
2. The attacker requests the same path with a doubled internal slash, e.g. /admin//secret.
3. The access rule, comparing the raw string, does not recognize this as the blocked path.
4. The underlying server or router collapses the doubled slash and resolves the request to the same protected route.

Prerequisites to Exploit

• A path-based access rule is enforced via exact string matching against the raw request path.
• The underlying server or router collapses repeated slashes during resolution.
• The attacker can insert extra slashes anywhere in the request path.

Vulnerable Code

BLOCKED_PATHS = {"/admin/secret"}

def check_access(path):
    if path in BLOCKED_PATHS:
        raise PermissionError("Access denied")

The check only matches the exact string "/admin/secret", so a request for "/admin//secret" bypasses it while the web server still routes it to the same protected resource.

Secure Code

import re

BLOCKED_PATHS = {"/admin/secret"}

def check_access(path):
    normalized = re.sub(r"/+", "/", path)
    if normalized in BLOCKED_PATHS:
        raise PermissionError("Access denied")

Collapsing repeated slashes to one before the comparison ensures both /admin/secret and /admin//secret are evaluated identically.

Business Impact of Path Equivalence

Confidentiality: Attackers may reach paths that a raw-string access rule was meant to protect.

Integrity: Attackers may reach write-capable routes bypassed by the same normalization gap.

• Bypass of web application firewall rules written as literal path patterns
• Inconsistent protection across proxy, server, and application layers with differing slash-normalization behavior

Path Equivalence Attack Scenario

1. An attacker notices a WAF rule blocks direct requests to /admin/secret.
2. They request /admin//secret instead, inserting an extra internal slash.
3. The WAF’s literal pattern match does not recognize this as the blocked path and lets it through.
4. The backend server collapses the doubled slash and routes the request to the same protected resource.

How to Detect Path Equivalence

Manual Testing

• Identify path-based access rules implemented as exact string matches.
• Insert doubled or repeated slashes at various points in a value that should be blocked.
• Confirm whether the underlying server or router still resolves the modified path to the protected resource.

Automated Scanners (SAST / DAST)

Static analysis can flag path comparisons using simple string equality against raw request paths, while dynamic testing confirms whether the live server actually collapses repeated slashes to the blocked route.

PenScan Detection

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

False Positive Guidance

If every layer in the request path (proxy, server, application) treats repeated slashes as genuinely distinct from the single-slash form, this specific bypass does not apply — confirm actual normalization behavior before treating it as a real finding.

How to Fix Path Equivalence

• Normalize the path (collapsing repeated slashes to one) before evaluating any access rule.
• Apply access rules consistently across every layer of the request path (proxy, server, application).
• Never assume a raw string comparison matches what the underlying router will actually resolve.

Framework-Specific Fixes for Path Equivalence

• Node.js/Express: normalize with a regex collapsing repeated slashes before any access-rule comparison, as shown above.
• Java/Spring: ensure Spring’s URL pattern matching normalizes the path before applying security rules, and avoid raw string comparisons in custom filters.
• Python/Django: normalize the path with a regex before comparison, or rely on Django’s URL resolver rather than manual string matching.
• PHP: collapse repeated slashes with a regex before any path-based access decision.

How to Ask AI to Check Your Code for Path Equivalence

Path Equivalence Best Practices Checklist

✅ Normalize repeated slashes before evaluating any path-based access rule ✅ Apply access rules against the normalized path, not the raw request string ✅ Align slash-normalization behavior across proxy, server, and application layers ✅ Test blocked routes with doubled-slash variants during review

Path Equivalence FAQ

How do multiple internal slashes cause a path equivalence bypass?

Most filesystems and web servers collapse repeated slashes (“//”) down to a single one during resolution, so “/admin//secret” and “/admin/secret” resolve to the same resource even though an access rule comparing the raw string sees them as different values.

How is this different from Path Traversal?

Path Traversal escapes a restricted directory entirely using “../”; this weakness stays inside the intended path structure but exploits slash-collapsing normalization to bypass a rule keyed to the exact, un-collapsed string.

How would an attacker use this in a real attack?

If a web application firewall or access rule blocks requests matching an exact path like “/admin/secret”, an attacker inserting a doubled slash (“/admin//secret”) can bypass a rule that only checks the literal string, while the server still routes it to the same resource.

How do I detect this in my own application?

Test path-based access rules with doubled or repeated internal slashes inserted at various points, and confirm whether the resource remains reachable.

How do I fix this correctly?

Normalize the path (collapsing repeated slashes to one) before evaluating any access rule, so the comparison happens on the same canonical form the resolver will actually use.

How can this bypass a web application firewall specifically?

A WAF rule written as a literal pattern match against the exact request path can miss a doubled-slash variant if it doesn’t normalize the path first, even though the backend server resolves it to the exact same protected route.

How can PenScan help find this weakness?

PenScan tests path-based access controls with multiple internal slash variants to confirm whether blocked resources are still reachable.

Vulnerabilities Related to Path Equivalence

References

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