CVE-2026-43828

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 information exposure vulnerability (CVE-2026-43828) has been identified in the default cookie configuration of Apache Shiro's shiro-web module, which allows attackers who can observe a victim's network traffic to capture the victim's Shiro session or rememberMe cookie by inducing the victim's browser to send it over plaintext HTTP. Because the rememberMe cookie is valid for one year, a single capture can grant persistent re-authentication as the victim.

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.

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.

Details

Module Info

• Product: Apache Shiro
• Affected packages: org.apache.shiro:shiro-web
• 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-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 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. Browsers only withhold a cookie from unencrypted requests when the cookie carries the Secure attribute (CWE-614). Shiro's default configurations set the HttpOnly attribute on the cookies they issue but never the Secure attribute, so a cookie minted during an HTTPS session is still attached to any plaintext http:// request the browser makes to the same host.

Two sensitive cookies are affected. The rememberMe cookie is on by default in every Shiro web application: DefaultWebSecurityManager, the standard web security manager, unconditionally wires in a CookieRememberMeManager, whose default cookie template calls cookie.setHttpOnly(true) and cookie.setMaxAge(Cookie.ONE_YEAR) but never calls setSecure. The resulting one-year cookie holds the encrypted serialized principal that re-authenticates the user. The Shiro-native session cookie (JSESSIONID) is affected when an application opts into Shiro's own session management via DefaultWebSessionManager, whose constructor builds the session-ID cookie the same way:

public DefaultWebSessionManager() {
    Cookie cookie = new SimpleCookie(ShiroHttpSession.DEFAULT_SESSION_ID_NAME);
    cookie.setHttpOnly(true); //more secure, protects against XSS attacks
    this.sessionIdCookie = cookie;
    ...
}

SimpleCookie declares private boolean secure;, which defaults to false, and its saveTo method emits the Set-Cookie header with boolean secure = isSecure();, so the insecure template default propagates directly to the browser. The Spring integration in shiro-spring mirrors the same insecure defaults: AbstractShiroWebConfiguration resolves both shiro.sessionManager.cookie.secure and shiro.rememberMeManager.cookie.secure with a ?: false fallback.

To exploit the flaw, an attacker positioned to observe the victim's traffic (for example on an open wireless network) induces the victim's browser to issue a cleartext http:// request to the HTTPS application's host, such as by injecting an http:// image reference or redirect into any unencrypted page the victim loads. Because the Shiro cookies lack the Secure attribute, the browser attaches them to that plaintext request, and the attacker captures the session identifier (an immediate session hijack) or the rememberMe token (persistent re-authentication as the victim). Applications that explicitly enable the secure flag on these cookies in their own configuration are not exposed; the vulnerability lies in the shipped defaults.

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.

Until an upgrade is possible, applications are not exposed if they explicitly enable the secure flag on Shiro's session and rememberMe cookies in their own configuration, for example by setting the shiro.sessionManager.cookie.secure and shiro.rememberMeManager.cookie.secure properties to true in Spring environments.

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

• Meteor_Kai (finder)