CVE-2026-48589: Apache Shiro Auth Bypass Vulnerability

CVE-2026-48589 Overview

CVE-2026-48589 is an open redirect vulnerability in Apache Shiro's Jakarta EE integration module. The flaw resides in post-login redirect handling, where the module trusts the HTTP Referer header to determine the redirect target. Insufficient validation of this client-controlled value allows an attacker to influence where authenticated users are sent after login. The issue affects Apache Shiro versions 2.0-alpha through 2.2.0, and 3.0.0-alpha-1, but only when applications integrate the shiro-jakarta-ee module. The weakness is classified as [CWE-601] URL Redirection to Untrusted Site.

Critical Impact

Attackers can craft links that, once a victim authenticates through a trusted Shiro-protected application, redirect them to attacker-controlled domains for phishing or credential harvesting.

Affected Products

• Apache Shiro 2.0-alpha through 2.2.0 (Jakarta EE module)
• Apache Shiro 3.0.0-alpha-1 (Jakarta EE module)
• Applications using the shiro-jakarta-ee integration module

Discovery Timeline

• 2026-05-25 - CVE-2026-48589 published to NVD
• 2026-05-25 - Apache Shiro project published security advisory
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-48589

Vulnerability Analysis

Apache Shiro is a Java security framework that handles authentication, authorization, cryptography, and session management. The Jakarta EE integration module provides Servlet filters and helpers for applications built on the Jakarta EE platform. After a successful user login, the module determines where to redirect the user. In certain code paths, that decision relies on the inbound HTTP Referer request header.

The Referer header is set by the user's browser and is fully controllable by an attacker who crafts the initial request. When Shiro reads this value to build the post-login redirect URL without restricting it to a same-origin or allowlisted host, the application becomes an open redirector. A victim who follows an attacker-supplied link and authenticates legitimately can be silently forwarded to a malicious site under the attacker's control.

Root Cause

The root cause is missing validation of an untrusted, client-supplied input used in a security-sensitive decision. The Jakarta EE module treats the Referer value as a usable redirect target without enforcing host allowlisting, scheme restrictions, or relative-URL constraints. This matches the [CWE-601] pattern, where redirect destinations derived from request data must be validated against a fixed set of permitted locations.

Attack Vector

An attacker hosts a malicious page or sends a phishing link that triggers a navigation to a protected resource on the vulnerable application. The browser attaches the attacker-chosen Referer header (or the attacker crafts a request setting it through other means). The victim authenticates on the legitimate site. Shiro then issues a redirect to the attacker-controlled URL derived from the Referer. The destination page can mimic the original application and request credentials, multi-factor codes, or session tokens. Exploitation requires user interaction and authenticated context but no special privileges beyond a valid user account flow.

Detection Methods for CVE-2026-48589

Indicators of Compromise

• HTTP Referer headers in access logs that point to external domains immediately preceding successful authentication events on Shiro-protected endpoints.
• Post-login 302 or 303 responses with Location headers pointing to hosts outside the application's known domain set.
• Unusual spikes in outbound redirects from login or callback URLs handled by the shiro-jakarta-ee module.

Detection Strategies

• Inventory all applications that depend on shiro-jakarta-ee between versions 2.0-alpha and 2.2.0, and 3.0.0-alpha-1, using software composition analysis against build manifests.
• Inspect web server and reverse proxy logs for login flows where the Referer host differs from the application host and the subsequent redirect leaves the trusted domain.
• Add web application firewall rules to flag authentication requests with cross-origin Referer values pointing to newly registered or low-reputation domains.

Monitoring Recommendations

• Alert on outbound Location headers from authentication endpoints whose host is not in an internal allowlist.
• Correlate user reports of unexpected post-login navigation with concurrent log entries showing external Referer values.
• Track phishing telemetry for lookalike domains targeting applications known to use Apache Shiro.

How to Mitigate CVE-2026-48589

Immediate Actions Required

• Upgrade Apache Shiro to a fixed release as published in the Apache Shiro Security Reports.
• Audit application code for any custom logic that propagates the Referer header into redirects and remove or constrain it.
• Restrict post-login redirects to a server-side allowlist of internal paths or hosts.

Patch Information

The Apache Shiro project addresses the issue in versions later than 2.2.0 and after 3.0.0-alpha-1. Refer to the Apache Shiro Security Reports and the Openwall OSS Security Announcement for fixed version details and upgrade guidance. The EPSS score for this vulnerability is 0.038% at the 11.853 percentile, indicating low near-term exploitation probability, but patching remains the durable fix.

Workarounds

• Configure the application to ignore the Referer header during login redirect resolution and use a fixed landing URL instead.
• Deploy a reverse proxy or WAF rule that strips or normalizes the Referer header on authentication endpoints.
• Enforce a strict same-origin redirect policy in application filters that wrap Shiro's Jakarta EE integration.

# Example WAF rule (pseudocode) to block cross-origin Referer on login endpoints
SecRule REQUEST_URI "@beginsWith /login" \
  "chain,deny,status:400,id:1004826,msg:'Cross-origin Referer on Shiro login'"
SecRule REQUEST_HEADERS:Referer "!@beginsWith https://app.example.com/"