CVE-2026-43827

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 core SecurityManager component processes every application login and manages each subject's session, whether sessions come from the servlet container or from Shiro's native session manager.

A weak authentication vulnerability (CVE-2026-43827) has been identified in Apache Shiro's default configurations, which allows attackers to hijack a victim's authenticated session through session fixation. When a session already exists at the time of login, Shiro neither invalidates it nor generates a new session with a new ID upon successful authentication, so an attacker who plants a known session ID in a victim's browser before the victim logs in inherits the authenticated session afterward.

Per OWASP: Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID; when authenticating a user, the vulnerable web application does not assign a new session ID, making it possible to use an existent session ID.

This issue affects all versions of Apache Shiro from 1.0.0-incubating up to but not including 2.2.0, as well as the 3.0.0-alpha-1 pre-release, including every release of the End-of-Life 1.x line.

Details

Module Info

• Product: Apache Shiro
• Affected packages: org.apache.shiro:shiro-core
• Affected versions: >=1.0.0-incubating <2.2.0, 3.0.0-alpha-1
• 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 Medium-severity vulnerability is found in the org.apache.shiro:shiro-core package in versions of Apache Shiro from 1.0.0-incubating up to but not including 2.2.0, as well as 3.0.0-alpha-1. The DefaultSecurityManager.login() method is the single choke point that every Subject.login(token) call goes through, and on successful authentication it transitions straight from authenticating the token to creating the logged-in subject, without invalidating or rotating any session that already exists:

public Subject login(Subject subject, AuthenticationToken token) throws AuthenticationException {
    AuthenticationInfo info;
    try {
        info = authenticate(token);
    } catch (AuthenticationException ae) {
        // (failure handling omitted)
        throw ae; //propagate
    }

    Subject loggedIn = createSubject(token, info, subject);

    onSuccessfulLogin(token, info, loggedIn);

    return loggedIn;
}

Because the pre-authentication session, and its ID, simply carry over to the authenticated subject, any deployment where a session exists before login is exposed. That is the default in web applications: shiro-web's ServletContainerSessionManager piggybacks on the container HttpSession, and Shiro's native session manager behaves the same way here. An attacker first fixates a session ID in the victim's browser (for example through a cookie planted via a subdomain or a flaw elsewhere in the site, a shared terminal, or any other session-adoption vector), then waits for the victim to authenticate. Since the ID is never changed at login, the attacker's known session ID now identifies an authenticated session, giving the attacker access to the victim's account. No configuration beyond the defaults is required, and Shiro 1.x provides no built-in hook through which an application could rotate the session at login.

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 2.2.0 (2.x line) and 3.0.0 (3.x line).
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Rasmus Moorats (finder)