This is an automated email from the ASF dual-hosted git repository. lprimak pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/shiro-site.git
commit 6e7668d79310c0680d63a4bafbbc78ed19c62e1c Author: lprimak <[email protected]> AuthorDate: Wed May 6 21:48:03 2026 -0500 security: added shiroSavedRequest cookie CVE --- src/site/content/security-reports.adoc | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/site/content/security-reports.adoc b/src/site/content/security-reports.adoc index a5ffa92d7..fc63d8001 100644 --- a/src/site/content/security-reports.adoc +++ b/src/site/content/security-reports.adoc @@ -30,6 +30,16 @@ A https://www.apache.org/security/committers.html[more detailed description of t == Apache Shiro Vulnerability Reports +=== link:https://www.cve.org/CVERecord?id=CVE-2026-44598[CVE-2026-44598] +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 an HTTP GET request from the server itself to an arbitrary URL from the cookie. + +**Mitigation:** +Upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue by encrypting the cookie. + +**Credit:** +Apache Shiro would like to thank *James Love* for reporting this issue. + === link:https://www.cve.org/CVERecord?id=CVE-2026-43827[CVE-2026-43827] 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, 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.
