CVE-2022-22978: Spring Security Auth Bypass Vulnerability

CVE-2022-22978 Overview

CVE-2022-22978 is an authorization bypass vulnerability in VMware Spring Security that allows attackers to circumvent access controls in applications using RegexRequestMatcher with . (dot) in the regular expression. The vulnerability stems from how certain servlet containers handle newline characters in request URIs, which can cause the regex pattern matching to fail unexpectedly, granting unauthorized access to protected resources.

Critical Impact

Attackers can bypass authentication and authorization controls to access protected endpoints without valid credentials, potentially leading to complete system compromise.

Affected Products

• VMware Spring Security versions prior to 5.4.11, 5.5.7, and 5.6.4
• Oracle Financial Services Crime and Compliance Management Studio (versions 8.0.8.2.0 and 8.0.8.3.0)
• NetApp Active IQ Unified Manager (Linux, VMware vSphere, and Windows)

Discovery Timeline

• 2022-05-19 - CVE-2022-22978 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-22978

Vulnerability Analysis

This authorization bypass vulnerability exists in Spring Security's RegexRequestMatcher class, which is commonly used to define URL patterns for access control rules. The vulnerability is classified under CWE-863 (Incorrect Authorization), indicating a fundamental flaw in how authorization decisions are made.

The issue arises when developers configure RegexRequestMatcher with regular expressions containing the . (dot) metacharacter. In regex syntax, . typically matches any single character except newline characters. When a malicious request contains a newline character (%0a or %0d) in the URI path, the regex matching can be bypassed on certain servlet containers, allowing the request to proceed without proper authorization checks.

The vulnerability requires no user interaction and can be exploited remotely over the network without any privileges, making it particularly dangerous for internet-facing applications. Successful exploitation grants attackers unauthorized access to protected resources, potentially compromising confidentiality, integrity, and availability of the application.

Root Cause

The root cause lies in the default behavior of Java's regex engine when using the . metacharacter. By default, . does not match newline characters (\n, \r). When developers write security rules using patterns like /admin/.* to protect administrative endpoints, attackers can inject newline characters into request URIs (e.g., /admin/test%0a/public) that cause the regex to fail matching, bypassing the security rule entirely. The regex engine stops matching at the newline, and depending on the servlet container's URL normalization behavior, the request may still route to the protected resource.

Attack Vector

The attack vector is network-based and can be executed by crafting HTTP requests with URL-encoded newline characters inserted into protected URL paths. An attacker identifies endpoints protected by RegexRequestMatcher rules, then constructs malicious requests by embedding %0a (line feed) or %0d (carriage return) characters at strategic points in the URL. When the servlet container processes the request, the regex-based security check fails to match the pattern due to the newline, while the backend routing still resolves to the protected resource.

For example, if an application protects /api/admin.* using RegexRequestMatcher, an attacker might send a request to /api/admin%0a or /api/admin%0d%0a/test. The regex pattern fails to match the full path due to the newline, potentially allowing the request to bypass authorization and reach the protected endpoint.

Detection Methods for CVE-2022-22978

Indicators of Compromise

• HTTP requests containing URL-encoded newline characters (%0a, %0d, %0d%0a) in URI paths
• Access log entries showing unusual character sequences in request URIs targeting protected endpoints
• Successful access to administrative or protected endpoints from unauthorized sources
• Web application firewall (WAF) logs showing blocked or flagged requests with encoded control characters

Detection Strategies

• Implement web application firewall rules to detect and block requests containing %0a, %0d, or other URL-encoded control characters in URI paths
• Monitor application access logs for requests with unusual URL encoding patterns, particularly targeting sensitive endpoints
• Deploy runtime application self-protection (RASP) solutions to detect authorization bypass attempts
• Use static code analysis tools to identify RegexRequestMatcher configurations using vulnerable . patterns

Monitoring Recommendations

• Enable verbose logging for Spring Security authorization decisions to identify failed or bypassed access control checks
• Set up alerts for access to protected resources from unexpected IP addresses or without proper authentication tokens
• Monitor for sudden increases in 403/401 responses followed by successful accesses to the same endpoints, which may indicate bypass attempts

How to Mitigate CVE-2022-22978

Immediate Actions Required

• Upgrade Spring Security to versions 5.4.11+, 5.5.7+, or 5.6.4+ immediately
• Review all RegexRequestMatcher configurations in your application for patterns using . without proper flags
• Implement input validation at the web server or WAF level to reject requests containing URL-encoded newline characters
• Audit access logs for potential exploitation attempts against your environment

Patch Information

VMware has released patched versions of Spring Security that address this vulnerability. Organizations should upgrade to Spring Security version 5.4.11 or later for the 5.4.x branch, 5.5.7 or later for the 5.5.x branch, or 5.6.4 or later for the 5.6.x branch. Refer to the Spring Security Advisory CVE-2022-22978 for detailed upgrade instructions and release notes.

Workarounds

• Replace RegexRequestMatcher with AntPathRequestMatcher where possible, as it is not affected by this vulnerability
• If regex patterns must be used, enable the DOTALL flag (Pattern.DOTALL or (?s) inline flag) to ensure . matches all characters including newlines
• Implement URL normalization at the reverse proxy or load balancer level to strip or reject control characters before they reach the application
• Add explicit input validation to reject HTTP requests containing newline characters in URI paths

# Example: Update Spring Security dependency in Maven pom.xml
# Change from vulnerable version:
# <spring-security.version>5.5.6</spring-security.version>
# To patched version:
# <spring-security.version>5.5.7</spring-security.version>

# For Gradle, update build.gradle:
# implementation 'org.springframework.security:spring-security-core:5.5.7'

# Verify the update by checking dependency tree:
mvn dependency:tree | grep spring-security