Apache Shiro is a popular security framework for Java, commonly used to handle authentication and authorization in web applications. In 2022, the project disclosed a vulnerability—CVE-2022-32532—which exposes a big risk: attackers can bypass authorization checks simply because of how Java regular expressions are handled under certain servlet containers. Let’s break it down in simple terms, look at the code, and see how the exploit works.

TL;DR

- If you used Apache Shiro before v1.9.1 with a custom path matcher using regex, you might be affected.
- If your regex uses a . (dot) without "dotall" or "multiline" flags, attackers can trick the security checks.

What’s the Root Cause?

Shiro lets developers define which URLs require authorization using matchers. One convenient matcher is the RegexRequestMatcher, where you supply a regular expression pattern. But if your expression uses a . to match a character—such as /secure/.*—and your server (like Tomcat) puts the full request path, including line breaks, into the string, the . won’t match newline characters by default.

Why is That a Problem?

Attackers can craft requests with newline characters in them (yes, it’s possible!), and the regex fails to match them, bypassing your security filter.

Suppose you have this in shiro.ini

[urls]
/secure/.* = authc, roles[admin]

Shiro will check if an incoming request path matches /secure/.*. The expectation: only logged-in users with the admin role should get access.

But by default, . in regex does not match newline. So let’s say someone sends a request to /secure/\nsecret-file, Shiro’s matcher may fail to detect it—depending on the servlet container.

Exploit Details

An attacker can generate a request with a newline character in the middle of the path to sneak past the matcher:

GET /secure/%asecret-file HTTP/1.1
Host: victim.com
Cookie: JSESSIONID=...

%a is a URL-encoded line feed (\n).

- Shiro’s .*/ matcher fails to see this as under /secure/.

Realistic Exploit Scenario

Note: Not every servlet container passes newline characters through, but some do (including certain Tomcat and Jetty versions).

Here's an end-to-end conceptual PoC in code

// Example Java code to simulate the path matcher (simplified)

String regex = "/secure/.*";
Pattern pattern = Pattern.compile(regex);

String dangerousPath = "/secure/\nsecret-file";

Matcher matcher = pattern.matcher(dangerousPath);
if (matcher.matches()) {
    System.out.println("Authorized path!");
} else {
    System.out.println("Path bypassed!");
}

// Output: Path bypassed!

*If your application checks URLs this way, anyone can bypass by inserting newlines.*

How to Fix

Best Fix:  
Upgrade to Apache Shiro 1.9.1 or later.  
Shiro 1.9.1 changes behavior to prevent this issue by using Pattern.DOTALL automatically (so . matches newlines as well).

Workaround:

If you can’t upgrade, make sure you adjust your regex or set the DOTALL flag

Pattern pattern = Pattern.compile("/secure/.*", Pattern.DOTALL);

Or in your Shiro configuration (if possible)

[urls]
/secure/.*(?s) = authc, roles[admin]   # Use inline (?s) flag for dotall, if supported

Official CVE page:

https://nvd.nist.gov/vuln/detail/CVE-2022-32532

Apache Shiro Security Advisory:

https://shiro.apache.org/security.html

Patch Commit:

https://github.com/apache/shiro/commit/ad3481c

Shiro Issue Tracker Report:

https://issues.apache.org/jira/browse/SHIRO-866

Conclusion

CVE-2022-32532 is a classic example of how small misconfigurations can lead to big security holes. It shows how important it is to know how libraries and language features (like regex!) behave in real-world conditions. If you use Apache Shiro, upgrade now and check all your path matchers—attackers never sleep.


*Stay safe and always check how your tools do their magic behind the scenes!*

Timeline

Published on: 06/29/2022 00:15:00 UTC
Last modified on: 07/08/2022 01:24:00 UTC