CVE-2026-23901

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-core module provides the realm and credentials-matching machinery that Shiro applications use to authenticate user login attempts.

An information exposure vulnerability (CVE-2026-23901) has been identified in Apache Shiro, which allows attackers to determine which usernames exist on a system by timing failed login attempts. Authentication attempts for non-existent users fail measurably faster than attempts for existing users with an incorrect password, because only the latter run the configured credentials matcher.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits. A timing side channel in the login path is such a failure: the time a rejected login takes reveals whether an account exists, information the application never intended to expose.

This issue affects all versions of Apache Shiro prior to 2.1.0.

Details

Module Info

• Product: Apache Shiro
• Affected packages: org.apache.shiro:shiro-core
• Affected versions: <2.1.0
• GitHub repository: https://github.com/apache/shiro
• Published packages: https://central.sonatype.com/artifact/org.apache.shiro/shiro-core
• 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 Low-severity vulnerability is found in the org.apache.shiro:shiro-core package in all versions of Apache Shiro prior to 2.1.0. Every stock Shiro realm authenticates through AuthenticatingRealm.getAuthenticationInfo(token); the class is the base of IniRealm, JdbcRealm, the LDAP and Active Directory realms, and virtually all custom realms. After looking up the submitted principal, the method only runs the configured CredentialsMatcher when an account was actually found:

if (info != null) {
    assertCredentialsMatch(token, info);
} else {
    log.debug("No AuthenticationInfo found for submitted AuthenticationToken [{}].  Returning null.", token);
}

When doGetAuthenticationInfo finds no account for the submitted username, the attempt fails immediately without any credentials matching. When the account exists but the password is wrong, the credentials matcher runs; with a work-factor-based matcher such as HashedCredentialsMatcher or PasswordMatcher (iterated, salted hashes), that check is deliberately expensive and can take orders of magnitude longer than the short-circuit path. An attacker who can submit login attempts with candidate usernames, for example through a form login endpoint, and measure how long each failure takes can therefore distinguish valid usernames from invalid ones. This is an observable timing discrepancy (CWE-208). The signal is easiest to measure for an attacker positioned close to the application, since network jitter makes remote exploitation considerably harder, and the impact is limited to username enumeration.

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.

The Apache Shiro advisory additionally recommends enforcing brute-force protections at the infrastructure level, which restricts an attacker's ability to collect the repeated timing samples this attack requires.

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

Credits

• 4ra1n (finder)
• Y4tacker (finder)