CVE-2026-23903: 
Java vulnerability analysis and mitigation

CVE-2026-23903 is an Authentication Bypass by Alternate Name vulnerability (CWE-289) in Apache Shiro's web component (org.apache.shiro:shiro-web). It affects all versions of Apache Shiro before 2.0.7 and allows unauthenticated remote attackers to access protected static files by varying the case of the filename in HTTP requests on case-insensitive filesystems. The vulnerability was disclosed on February 8–9, 2026, with a fix available in Shiro 2.0.7. It carries a CVSS v3.1 base score of 5.3 (Medium) (Feedly, Openwall OSS-Sec).

The root cause is that Apache Shiro's filter chain resolver performs case-sensitive path matching by default. On case-insensitive filesystems (e.g., the default macOS HFS+/APFS setup), a request for /Protected/File.html and /protected/file.html resolve to the same file, but Shiro's filters — typically configured with lowercase paths — only match the lowercase variant. An attacker can bypass authentication and authorization filters by requesting a static file with altered casing (e.g., /Protected/Secret.pdf instead of /protected/secret.pdf), causing the filter chain to not apply and the file to be served directly. This is classified as CWE-289 (Authentication Bypass by Alternate Name) and is limited to static file access; dynamic endpoints are not affected (Openwall OSS-Sec, Red Hat Bugzilla).

Successful exploitation allows an unauthenticated network attacker to read protected static files (e.g., configuration files, documents, or sensitive resources) that should require authentication or authorization. The confidentiality impact is limited to static file disclosure; integrity and availability are not affected. The scope is restricted to deployments running on case-insensitive filesystems with lowercase-only Shiro filter configurations (Feedly, Openwall OSS-Sec).

1. Reconnaissance: Identify web applications using Apache Shiro versions before 2.0.7 as their security framework, particularly those hosted on macOS or other case-insensitive filesystems. Tools like Shodan, Censys, or HTTP response header analysis can help identify Shiro-protected applications.
2. Identify protected static resources: Browse the application to enumerate static file paths (e.g., /protected/report.pdf, /admin/config.json) that return 401/403 responses when accessed normally.
3. Craft case-variant request: Modify the case of one or more path components in the URL (e.g., change /protected/report.pdf to /Protected/report.pdf or /PROTECTED/report.pdf).
4. Send the request: Issue an unauthenticated HTTP GET request with the case-modified path. On a case-insensitive filesystem, the server resolves the file correctly, but Shiro's lowercase-only filter chain does not match the altered path and skips authentication enforcement.
5. Access protected file: The static file is returned without authentication, completing the bypass (Openwall OSS-Sec, Red Hat Bugzilla).

• Network: HTTP GET requests to static file paths with mixed or uppercase characters in path segments that would normally be lowercase (e.g., /Protected/, /Admin/, /Secure/), particularly returning HTTP 200 responses for resources that should require authentication.
• Logs: Web server access logs showing successful (HTTP 200) responses to requests with case-variant paths for protected static resources from unauthenticated sessions; absence of corresponding Shiro authentication log entries for those requests.
• Application Logs: Shiro filter chain logs that do not record a filter match or authentication check for requests that successfully retrieved protected static files.

Upgrade to Apache Shiro version 2.0.7 or later, which introduces a configurable case-insensitive filter chain resolver. If immediate upgrade is not possible, enable case-insensitive filtering via configuration: set filterChainResolver.caseInsensitive = true in shiro.ini, or shiro.caseInsensitive=true in application.properties. Apache Shiro 3.0.0 (upcoming) will make case-insensitive filtering the default. As an additional measure, consider deploying on case-sensitive filesystems (e.g., Linux ext4) where the bypass condition does not exist (Openwall OSS-Sec, Red Hat Bugzilla).

The vulnerability was reported by Jesse Yang (finder) and remediated by Lenny Primak, who also disclosed it to the oss-security mailing list on February 8, 2026. Red Hat tracked the issue via Bugzilla and assigned it medium severity. Oracle included it in their April 2026 Critical Patch Update. Community reaction has been muted given the limited scope (case-insensitive filesystems only) and low CVSS score (Openwall OSS-Sec, Oracle CPU Apr 2026).