Apache Shiro’s Jakarta EE module used the HTTP Referer header in certain cases to issue redirect after a user login.
In affected versions, insufficient validation of this client-controlled value could allow an attacker to influence the redirect target in applications using the Jakarta EE module.
This issue affects Apache Shiro from 2.0-alpha to 2.2.0, and 3.0.0-alpha-1, only when using shiro-jakarta-ee integration module.
Default configurations of Apache Shiro have a session fixation vulnerability.
This issue affects Apache Shiro from 1.0 to 2.1.0, and 3.0.0-alpha-1.
Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue.
In the affected versions, when a session already exists, it is not invalidated upon successful login, nor is a new session being generated with a new ID.
Default configurations of Apache Shiro send sensitive cookies in HTTPS session without 'Secure' attribute.
This issue affects Apache Shiro from 1.0 to 2.1.0, and 3.0.0-alpha-1.
Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue.
In the affected versions, Shiro-native session manager, as well as Remember-Me manager sends JSESSIONID and rememberMe cookies without 'secure' attribute by default.
With valid login credentials, URL Redirection to Untrusted Site ('Open Redirect'), Server-Side Request Forgery (SSRF) vulnerability in Apache Shiro.
This issue affects Apache Shiro from 2.0-alpha to 2.1.0, and 3.0.0-alpha-1, only when using shiro-jakarta-ee integration module.
Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue by encrypting the cookie.
After successful login, Jakarta EE integration module uses shiroSavedRequest cookie to redirect to a particular web page after login.
This cookie was not validated, and can be forged to send a HTTP GET request from the server itself to an arbitrary URL from the cookie.
Observable Timing Discrepancy vulnerability in Apache Shiro.
This issue affects Apache Shiro: from 1.*, 2.* before 2.0.7.
Users are recommended to upgrade to version 2.0.7 or later, which fixes the issue.
Prior to Shiro 2.0.7, code paths for non-existent vs. existing users are different enough,
that a brute-force attack may be able to tell, by timing the requests only, determine if
the request failed because of a non-existent user vs. wrong password.
The most likely attack vector is a local attack only.
Shiro security model https://shiro.apache.org/security-model.html#username_enumeration discusses this as well.
Typically, brute force attack can be mitigated at the infrastructure level.
Authentication Bypass by Alternate Name vulnerability in Apache Shiro.
This issue affects Apache Shiro: before 2.0.7.
Users are recommended to upgrade to version 2.0.7, which fixes the issue.
The issue only effects static files. If static files are served from a case-insensitive filesystem,
such as default macOS setup, static files may be accessed by varying the case of the filename in the request.
If only lower-case (common default) filters are present in Shiro, they may be bypassed this way.
Shiro 2.0.7 and later has a new parameters to remediate this issue
shiro.ini: filterChainResolver.caseInsensitive = true
application.propertie: shiro.caseInsensitive=true
Shiro 3.0.0 and later (upcoming) makes this the default.
Apache Shiro before 1.13.0 or 2.0.0-alpha-4, may be susceptible to a path traversal attack that results in an authentication bypass when used together with path rewriting
Mitigation: Update to Apache Shiro 1.13.0+ or 2.0.0-alpha-4+, or ensure `blockSemicolon` is enabled (this is the default).
URL Redirection to Untrusted Site ('Open Redirect') vulnerability when "form" authentication is used in Apache Shiro.
Mitigation: Update to Apache Shiro 1.13.0+ or 2.0.0-alpha-4+.
Apache Shiro, before 1.12.0 or 2.0.0-alpha-3, may be susceptible to a path traversal attack that results in an authentication bypass when used together with APIs or other web frameworks that route requests based on non-normalized requests.
Mitigation: Update to Apache Shiro 1.12.0+ or 2.0.0-alpha-3+
When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+, a specially crafted HTTP request may cause an authentication bypass.
The authentication bypass occurs when Shiro and Spring Boot are using different pattern-matching techniques. Both Shiro and Spring Boot < 2.6 default to Ant style pattern matching.
Mitigation: Update to Apache Shiro 1.11.0, or set the following Spring Boot configuration value: `spring.mvc.pathmatch.matching-strategy = ant_path_matcher`