CVE-2022-32532 Overview
CVE-2022-32532 is an authorization bypass vulnerability in Apache Shiro before version 1.9.1. The vulnerability exists in the RegexRequestMatcher component, which can be misconfigured to be bypassed on certain servlet containers. Applications using RegExPatternMatcher with a dot (.) character in the regular expression are potentially vulnerable to authorization bypass attacks.
This flaw allows unauthenticated attackers to circumvent security controls and access protected resources that should require authentication or specific permissions. The vulnerability stems from improper handling of newline characters in request paths, enabling attackers to craft malicious requests that evade regex-based security filters.
Critical Impact
Remote unauthenticated attackers can bypass authorization controls to access protected resources, potentially leading to unauthorized data access, privilege escalation, and full system compromise.
Affected Products
- Apache Shiro versions prior to 1.9.1
- Applications using RegExPatternMatcher with . in regular expressions
- Java web applications deployed on servlet containers with Apache Shiro security
Discovery Timeline
- 2022-06-29 - CVE-2022-32532 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2022-32532
Vulnerability Analysis
This authorization bypass vulnerability (CWE-863) affects Apache Shiro's RegexRequestMatcher component, which is responsible for matching incoming HTTP request paths against configured regular expression patterns to enforce security policies.
The root issue lies in how Java's regex engine interprets the dot (.) metacharacter. In standard regex, a dot matches any character except newline characters by default. When developers configure Shiro's RegExPatternMatcher with patterns like /admin/.* to protect administrative endpoints, they expect it to match any path starting with /admin/. However, attackers can inject newline characters (%0a or %0d) into the request path, causing the regex match to fail while the underlying servlet container still processes the request to the protected resource.
For example, a pattern configured to protect /admin/.* would fail to match a crafted request to /admin/sensitive%0aresource, allowing the request to bypass authorization checks while still reaching the protected endpoint on vulnerable servlet containers.
Root Cause
The vulnerability originates from the default behavior of Java's Pattern class when using the dot metacharacter. Without the Pattern.DOTALL flag, the dot does not match line terminators including carriage return (\r) and newline (\n) characters. When Shiro's RegExPatternMatcher evaluates a URL containing encoded newline characters against a protection pattern, the regex engine fails to match, causing the security filter to incorrectly allow the request through.
Additionally, certain servlet containers normalize or process URLs containing newline characters differently, creating a mismatch between what Shiro's security filter evaluates and what the underlying application ultimately receives and processes.
Attack Vector
The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending specially crafted HTTP requests containing URL-encoded newline characters (%0a, %0d, or %0d%0a) to bypass regex-based path matching in Shiro's security filters.
The attack flow typically involves:
- Identifying protected endpoints that use RegExPatternMatcher for authorization
- Crafting a malicious URL with embedded newline characters after the protected path prefix
- Sending the request to the target application
- Bypassing authorization checks while the servlet container processes the request to the intended protected resource
The vulnerability is particularly dangerous because it requires no special privileges and can be exploited by any remote attacker who can send HTTP requests to the affected application. See the Apache Mailing List Discussion for additional technical details.
Detection Methods for CVE-2022-32532
Indicators of Compromise
- HTTP requests containing URL-encoded newline characters (%0a, %0d) in path segments
- Access log entries showing unusual path patterns with encoded characters accessing protected resources
- Successful access to administrative or protected endpoints from unauthenticated sessions
- Anomalous patterns in web application logs showing requests with malformed URLs reaching protected handlers
Detection Strategies
- Implement WAF rules to detect and block requests containing %0a, %0d, or %0d%0a in URL paths
- Deploy IDS/IPS signatures to identify regex bypass attempt patterns in HTTP traffic
- Enable detailed access logging on protected endpoints to detect unauthorized access attempts
- Configure SentinelOne Singularity to monitor for process behaviors indicative of post-exploitation activities following authorization bypass
Monitoring Recommendations
- Review Apache Shiro configuration files for RegExPatternMatcher usage with dot metacharacters in patterns
- Monitor application access logs for requests to sensitive endpoints that bypass normal authentication flows
- Set up alerts for access pattern anomalies on protected administrative resources
- Conduct periodic security assessments to identify misconfigured regex patterns in security filters
How to Mitigate CVE-2022-32532
Immediate Actions Required
- Upgrade Apache Shiro to version 1.9.1 or later immediately
- Review and audit all RegExPatternMatcher configurations in your Shiro security settings
- Implement input validation at the web server or WAF level to reject requests with encoded newline characters in paths
- Consider using AntPathMatcher instead of RegExPatternMatcher where possible as an alternative
Patch Information
Apache has addressed this vulnerability in Apache Shiro version 1.9.1. Organizations should upgrade to this version or later to remediate the vulnerability. The official advisory and discussion can be found on the Apache Mailing List.
When upgrading, ensure that the new version is properly deployed across all application instances and that the updated security configurations are tested in a staging environment before production deployment.
Workarounds
- If immediate upgrade is not possible, modify regex patterns to explicitly account for line terminators by using [\s\S] instead of .
- Implement URL normalization at the web server or reverse proxy level to reject or sanitize requests containing newline characters
- Deploy a Web Application Firewall (WAF) rule to block requests with %0a, %0d, or other encoded newline sequences in URL paths
- Consider switching to AntPathMatcher for path matching as a temporary measure while planning the upgrade
# Example: Nginx configuration to block requests with encoded newlines
location ~ "%0[ad]|%0[AD]" {
return 400;
}
# Example: Apache mod_rewrite rule to block encoded newline attacks
RewriteEngine On
RewriteCond %{THE_REQUEST} "%0[aAdD]" [NC]
RewriteRule .* - [F,L]
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

