Path Confusion

How Path Confusion Happens

Path confusion is a routing and interpretation failure, not just a parsing quirk. It appears when intermediaries and origin systems disagree about where one path ends and another begins, so the same request can be normalised one way by a proxy and another way by the server. That mismatch is what creates the security problem.

The issue usually arises from differences in delimiter handling, percent-encoding, dot-segment removal, or slash normalisation. A path that looks harmless to one component may be reinterpreted as targeting a different resource by another, which can undermine cache keys, access decisions, and request routing.

Why Path Confusion Is Dangerous

The main danger is that a request can be processed under two different assumptions at once. In a cache-proxy chain, that can let an attacker poison a cached response for a path that other users later request. In a broader application stack, it can create request smuggling-like confusion, bypass expected routing, or make the wrong backend resource appear to be the intended one.

Because path interpretation sits at the boundary between components, the failure is often subtle. Logging may show one path, the cache may store another, and the origin may serve content from a third interpretation. That makes the bug especially useful for deception and especially hard to reason about without testing the full request path end to end.

Common Causes and Parsing Differences

Path confusion is usually introduced by inconsistent URL canonicalisation. One component may decode encoded delimiters before matching, another may match first and decode later, and a third may preserve the raw path for cache lookup. Even small differences in how systems treat multiple slashes, encoded slashes, trailing separators, or path parameters can produce materially different results.

These bugs are often amplified when teams assume the reverse proxy, CDN, WAF, and origin all implement the same rules. They do not. The risk grows when security controls inspect one representation while the application or cache consumes another, because the control can be bypassed without the request ever appearing obviously malformed.

Security Impact and Defensive Review

Path confusion matters because it can weaken cache correctness, content isolation, and request integrity at the same time. If a poisoned response is cached under a broadly reused path, the impact can spread to other users. If a protected route is interpreted differently by front-end and back-end components, the confusion can also support access-control bypass or content exposure.

Defence starts with understanding how every hop in the request chain normalises paths, then verifying that those rules are consistent across proxies, caches, application routers, and origin handlers. Review configurations for decoding order, path rewriting, cache key construction, and any special handling of encoded separators or unusual delimiters.

How to Check for It in Practice

Testing should compare the raw request path, the proxy-visible path, and the origin-visible path. Useful checks include sending equivalent requests with different encodings, mixed separators, repeated slashes, and paths that differ only after decoding or canonicalisation. If two components disagree about the target resource, you have found a candidate path confusion condition.

Security review should also examine whether cache keys are built from the same normalised form that the origin uses to select content. Where possible, reject ambiguous requests early, apply one canonical path policy everywhere, and avoid letting intermediary-specific rewrites create a second interpretation of the same request.

Risk and Threat Considerations

Path confusion becomes most dangerous when it influences shared caching, security filtering, or backend routing. An attacker can use a deliberately ambiguous path to make one component store or allow a response that another component would not have accepted, turning a parsing mismatch into poisoning or access bypass.

Failure mechanism: Different components normalise, decode, or compare the same path at different stages, so the security decision is made on one representation while the request is served from another.

Impact: Cached content can be poisoned, protected content can be exposed, and request routing can become unreliable enough to support deception, misdelivery, or policy bypass.

Practitioner Guidance

Common misunderstanding: teams often assume that a path is a single, stable string. In practice, the security question is which interpretation each component uses, and whether those interpretations are provably identical for every request that matters.

What to watch for: any architecture where a proxy, cache, gateway, or application server rewrites paths, decodes before matching, or applies special-case canonicalisation. Treat those as high-value review points, especially when content is user-specific or access-controlled.

Practitioner takeaway: path confusion is prevented less by blocking “bad” strings than by eliminating inconsistent interpretation across the request chain.

Related resources from NHI Mgmt Group

• What are the signs that a Python application may be vulnerable to BadHost style path confusion?
• Why does a type confusion bug in a browser engine create such a high-risk attack path?
• What breaks when a dependency confusion package runs inside a Lambda build path?
• Why do leaked secrets need a different reporting path than ordinary software bugs?