CVE-2026-23903

Overview

Apache Shiro is an open-source Java security framework that performs authentication, authorization, cryptography, and session management for applications ranging from small mobile apps to large web and enterprise systems. Its shiro-web module installs Shiro as a servlet filter chain that enforces path-based authentication and authorization rules in front of the application.

An authorization bypass vulnerability (CVE-2026-23903) has been identified in Apache Shiro's filter chain path matching, which allows attackers to reach protected static files by varying the letter case of the request path. Shiro's default AntPathMatcher compares filter chain patterns to request paths case-sensitively, so a chain rule written for /secret.txt does not match a request for /SECRET.TXT, while a case-insensitive filesystem still resolves both names to the same file.

Per CWE-289: the product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.

This issue affects all released versions of Apache Shiro up to and including 2.0.6, including every release of the End-of-Life 1.x line. The fix first shipped in Apache Shiro 2.1.0.

Details

Module Info

• Product: Apache Shiro
• Affected packages: org.apache.shiro:shiro-web, org.apache.shiro:shiro-core, org.apache.shiro:shiro-spring
• Affected versions: <=2.0.6
• GitHub repository: https://github.com/apache/shiro
• Published packages: https://central.sonatype.com/artifact/org.apache.shiro/shiro-web
• Package manager: Maven
• Fixed in: NES for Apache Shiro 1.8.0-shiro-1.8.2 and 1.13.0-shiro-1.13.2

Vulnerability Info

This Medium-severity vulnerability is found in the org.apache.shiro:shiro-web package in all released versions of Apache Shiro up to and including 2.0.6. The filter chain resolution lives in shiro-web: PathMatchingFilterChainResolver.getChain() iterates the configured chain patterns and calls pathMatches(pattern, requestURI) for each one, delegating to the default path matcher, AntPathMatcher (shipped in org.apache.shiro:shiro-core). That matcher's character-comparison loop is strictly case-sensitive, and affected versions offer no option to change this:

for (int i = 0; i <= patIdxEnd; i++) {
    ch = patArr[i];
    if (ch != '?') {
        if (ch != strArr[i]) {
            return false;// Character mismatch
        }
    }
}

When an application protects static resources by path pattern (for example, a chain rule of /secret.txt = authc) and runs on a case-insensitive filesystem, the default on Windows and macOS, an attacker can request the same resource under an alternate-case path such as /SECRET.TXT. The matcher fails to match the configured pattern, so no filter chain is applied to the request, and the servlet container's static resource handler then resolves the alternate-case path to the same file and serves it without Shiro's authentication filter ever running. The bypass is limited to static files, because dynamic servlet mappings are generally case-sensitive; the impact is read access to otherwise protected static content.

Mitigation

Apache Shiro 1.x is End-of-Life and no longer receives open-source updates to address this issue. The final 1.x release was 1.13.0; as of February 28, 2024, Shiro v1 was superseded by v2.

Note that the upstream fix is opt-in: Apache Shiro 2.1.0 adds a case-insensitive matching option that must be enabled explicitly, with filterChainResolver.caseInsensitive = true in INI configuration or shiro.caseInsensitive = true in Spring Boot. Apache Shiro 3.0.0 enables case-insensitive matching by default. The NES for Apache Shiro fix is opt-in in the same way: enable it with the shiro.caseInsensitive=true property in Spring and Spring Boot applications, or with ShiroFilterFactoryBean.setCaseInsensitive(true).

Users of the affected components should apply one of the following mitigations:

• Upgrade Apache Shiro to a currently supported release line that contains the fix, first shipped upstream in Apache Shiro 2.1.0, and enable the case-insensitive matching option.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Jesse Yang (finder)