CVE-2023-46749

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.

A path traversal vulnerability (CVE-2023-46749) has been identified in the shiro-web filtering layer, which allows attackers to walk past a Shiro path-based authorization filter chain and reach a protected resource by rewriting the request path with a semicolon path parameter such as /something/..;jsessionid=x. When Shiro's request hardening does not recognize the rewritten sequence as traversal, the path Shiro authorizes against differs from the one the servlet container ultimately dispatches, resulting in an authentication or authorization bypass.

Per OWASP: A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with "dot-dot-slash (../)" sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files.

This issue affects all versions of Apache Shiro before 1.13.0, as well as the 2.0.0-alpha-1 through 2.0.0-alpha-3 pre-releases.

Details

Module Info

• Product: Apache Shiro
• Affected packages: org.apache.shiro:shiro-web
• Affected versions: <1.13.0, >=2.0.0-alpha-1 <2.0.0-alpha-4
• 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

Vulnerability Info

This Medium-severity vulnerability is found in the org.apache.shiro:shiro-web package in all versions of Apache Shiro before 1.13.0. Shiro's InvalidRequestFilter is the framework's global request-hardening filter: it is registered as the invalidRequest default filter and prepended to every filter chain of a stock INI-configured Shiro web application, so it screens every incoming request by default. In affected versions its validity check rejects only semicolons, backslashes, and non-ASCII characters, with no defense against path-rewriting traversal:

private boolean isValid(String uri) {
    return !StringUtils.hasText(uri)
           || ( !containsSemicolon(uri)
             && !containsBackslash(uri)
             && !containsNonAsciiCharacters(uri));
}

A request path that carries a semicolon path parameter after a .. segment, for example /something/..;jsessionid=foobar, is not recognized as a traversal sequence. Shiro selects the filter chain to enforce by matching the request path against the configured patterns, but the servlet container strips the ;jsessionid=... matrix parameter and normalizes the .. segment before it dispatches the request. As a result, Shiro authorizes one path while the container resolves the reshaped request to a different, protected resource, so the request slips past the authc/roles/perms filters that should have guarded it and the security checks configured for that resource are never applied.

In a default Shiro configuration the blockSemicolon option is enabled, which already rejects the raw ; in the URI and blocks this payload; the residual exposure is deployments that set blockSemicolon to false, or fronting proxies and servlet containers whose own path rewriting reintroduces the traversal after Shiro's decoded-path checks. The upstream fix adds a dedicated rewrite-traversal guard that blocks the /..; and /.; sequences independently of the blockSemicolon setting.

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.

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 1.13.0.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• No public finder credit is listed in the advisory sources checked for this entry.