[Maybe, hardening] Null path normalization in getPathWithinApplication causes complete filter chain bypass

[xaccefy]

Summary

WebUtils.getPathWithinApplication() can return null when the request path normalizes above root. This null propagates through PathMatchingFilterChainResolver.getChain() which cannot match any pattern (including /**), and AbstractShiroFilter.getExecutionChain() falls back to the original container FilterChain — bypassing all Shiro security filters.

Root Cause

Commit b90f918 (Shiro 1.5.3, CVE-2020-11989 fix) changed getPathWithinApplication() to:

return normalize(removeSemicolon(getServletPath(request) + getPathInfo(request)));

normalize() returns null when the path contains /../ at index 0 (trying to go above root). Unlike the old implementation (which always returned a valid path), this null is never handled downstream.

Impact

Complete authentication and authorization bypass. Requests that trigger this code path skip InvalidRequestFilter, authc, roles/perms, and all other Shiro filters. The downstream framework (Spring, JAX-RS, etc.) routes the request normally.

Attack Vector

An attacker sends a request where getServletPath() + getPathInfo() produces a path where normalize() returns null (e.g. path traversal above root). When the servlet container does not normalize the path before passing it to filters (some containers, configurations, or via RequestDispatcher.forward/include), this causes Shiro to skip all security checks.

Affected Versions

Shiro 1.5.3 through 3.0.0 — all versions since the normalize() call was introduced in getPathWithinApplication().

Suggested Fix

Return "/" instead of null from getPathWithinApplication() when normalize() fails, and add a /** fallback in PathMatchingFilterChainResolver. A PR with the fix and tests is available at #2836.

[lprimak]

Hi,
Thanks for reporting this bug. In the future, please use the security issue reporting procedure instead.

I am not able to reproduce this issue (the bypass part). The Servlet container normalizes the path before it ever gets to normalize() method.
Is this supposed to be a defence-in-depth hardening fix?

In any case, we need more information on how to reproduce.

[xaccefy]

Good question, I can explain.

This was found through code review — tracing normalize() -> getPathWithinApplication() -> getChain() -> getExecutionChain(). Not through dynamic testing.

I did just spin up a test app with embedded Tomcat 10.1 + Spring Boot to try a curl repro. Everything with /../ at root gets 400'd by Tomcat before it reaches the servlet. So you're right — you can't trigger this with a standard curl against a Spring Boot app.

The code path is real: if normalize() ever returns null (which it does for paths starting with /../), the null propagates straight through and no filter chain matches — not even **. But that precondition isn't hit in practice with modern Tomcat.

The fix is still worth having though. It's defense-in-depth:

• Prevents this class of bypass for any container/config that doesn't normalize paths (Jetty, Undertow, older Tomcat, /* mapped servlets)
• Makes Shiro's path handling correct regardless of the container
• Similar to how the CVE-2020-11989 fix added normalize() — it protected against scenarios that weren't broadly exploitable at the time but prevented future CVEs

Happy to reframe the PR as a robustness fix rather than a critical security issue. The code change is the same either way.

[lprimak]

I made a review on the PR.
Also, yes, please fix / rename the issue and PR so they don't sound as scary and confuse others to think there is a critical bug here.
Thank you

[lprimak]

Prevents this class of bypass for any container/config that doesn't normalize paths (Jetty, Undertow, older Tomcat, /* mapped servlets)

Can you provide a sample configuration of this? In somewhat (post-2020) servlet containers, I cannot find any configuration nor setting that will disable URI normalization and let this through.
Furthermore, the Servlet spec specifically states that URIs are decoded and normalized - see https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0#request-uri-path-processing

[lprimak]

Bottom line: Please provide a reproducer that uses somewhat modern software. Otherwise, this is all just guesses :)

[xaccefy]

Hey Lenny —

You were right — we tested every bypass technique we know against modern Tomcat 10.1 + Spring Boot, and all root-traversal paths get 400'd at the connector before Shiro sees them. No curl reproducer possible.

The code-level null path is real (it's in WebUtils.getPathWithinApplication when normalize() returns null), but the precondition isn't reachable from external HTTP in standard configs. Framed as defense-in-depth, the fix is still worth merging — it prevents hypothetical trigger paths (forward/include edge cases, nonstandard configs).

Happy to close if you'd rather scope it narrowly. Your call.

[lprimak]

I want to do the right thing that's least risky.

Is there an "edge case", hypothetical case or non-standard config mentioned that you can prove?

I think im ok with the "in depth" fix to Path matching filter, but the WebUtil change is just too risky for me.

[xaccefy]

I mean if there is somehow bypass the tomcat etc etc. The bypass should become real IF like it is a big If case so your shot to close or patch the issue

[lprimak]

Yea. Big if. I am pretty sure if that's the case, Shiro would be the least of the issues :)

[lprimak]

Got a different idea. What about throwing IllegalStateException? That way it will fail closed in all cases and not return anything in case of misconfiguration?

[xaccefy]

IllegalStateException sounds right — fail closed. I'll update the PR.