Spring Security CVE-2026-22753: Brief Summary of Servlet Path Matching Bypass in 7.0.x

Introduction

A subtle configuration interaction in Spring Security 7.0 can silently disable your entire security filter chain and leave protected endpoints wide open to unauthenticated access. CVE-2026-22753, disclosed on April 22, 2026, affects applications that combine securityMatchers(String) with a PathPatternRequestMatcher.Builder bean carrying a servlet path prefix. That combination is common in Spring Boot applications that use spring.mvc.servlet.path.

Nothing throws an error, and the bypass is not partial. The security filter chain never matches the intended requests, so authentication, authorization, and every other security component configured on that chain are never exercised. The vulnerability carries a CVSS 3.1 score of 7.5 (HIGH), and the attack vector is network-accessible with no authentication required. Any team running Spring Security 7.0.x should give it prompt attention.

Technical Information

Root Cause: Ignored Application Context Bean

The vulnerability lives in HttpSecurityConfiguration, specifically in how it resolves the PathPatternRequestMatcher.Builder it uses to construct security matchers.

In Spring Security 7.0.0 through 7.0.4, calling securityMatchers(String) caused the framework to construct a fresh, default PathPatternRequestMatcher.Builder internally. That builder knew nothing about any PathPatternRequestMatcher.Builder bean already published in the application context.

Spring Boot publishes such a bean automatically when you configure spring.mvc.servlet.path. For example, setting spring.mvc.servlet.path=/api causes Spring Boot to publish a PathPatternRequestMatcher.Builder bean with /api set as the basePath. The intent is that all path matching in the security layer accounts for this prefix.

Because the framework ignored the published bean, the securityMatchers matched against the raw path pattern, without the servlet path prefix. A configuration like this:

http
    .securityMatchers("/admin/**")

would attempt to match requests at /admin/** rather than /api/admin/**. The real incoming requests arrive at /api/admin/**, so the filter chain never matches them and no security controls are applied.

A Second Subtle Bug: Immutable Builder Misuse

PathPatternRequestMatcherFactoryBean, the factory bean that Spring Boot uses to publish the builder, had a compounding bug. The builder's basePath() method follows an immutable-style API. It returns a new Builder instance instead of mutating the current one. The original code was:

// Before (broken)
this.builder.basePath(this.basePath);

The return value was never reassigned, so the configured basePath was silently discarded. Even if the framework had looked up the bean from the application context, the bean itself would not have carried the correct servlet path. The one-line fix makes the published factory bean keep the intended servlet path:

// After (fixed)
this.builder = this.builder.basePath(this.basePath);

Attack Flow

An attacker needs no special tooling or credentials to exploit this vulnerability. The attack flow is straightforward:

1. The target application runs Spring Security 7.0.0 through 7.0.4 and configures spring.mvc.servlet.path to a non-default value (e.g., /api).
2. The application uses securityMatchers(String) to define which requests a particular security filter chain should handle.
3. Because of the bug, the filter chain does not match requests that arrive at the real, servlet-path-prefixed URL.
4. The attacker sends requests directly to the intended endpoints (e.g., GET /api/admin/users). The security filter chain does not match these requests, so no authentication or authorization checks are performed.
5. The attacker reaches resources that were meant to be protected without authenticating, and can read or modify data depending on what the endpoint does.

The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N reflects this: network accessible, low complexity, no privileges required, no user interaction, and high integrity impact.

Patch Information

The Spring Security team fixed CVE-2026-22753 in version 7.0.5, released on April 21, 2026. Only the 7.0.x line is vulnerable. Spring Security 6.x and earlier are not affected, because the interaction between string-based matchers and a published PathPatternRequestMatcher.Builder bean is unique to the 7.0 line.

The fix is spread across two main commits by Josh Cummings, both dated April 15, 2026.

Fix 1: HttpSecurityConfiguration.java

The core fix changes the createSharedObjects() method so that it prefers the application context bean to a newly constructed default builder.

Previously:

sharedObjects.put(PathPatternRequestMatcher.Builder.class, constructRequestMatcherBuilder(this.context));

Changed to:

sharedObjects.put(PathPatternRequestMatcher.Builder.class,
    this.context.getBeanProvider(PathPatternRequestMatcher.Builder.class)
        .getIfUnique(() -> constructRequestMatcherBuilder(this.context)));

The new code calls getBeanProvider(...).getIfUnique(...) to look up the PathPatternRequestMatcher.Builder bean from the application context. If a unique bean exists (typically the one Spring Boot publishes, with the servlet path already set as the basePath), the framework uses it directly. It falls back to constructing a new default builder only when no such bean is found. As a result, securityMatchers("/admin/**") now resolves correctly to /api/admin/** (or whatever the servlet path is) when a builder bean with that basePath is present.

Fix 2: PathPatternRequestMatcherFactoryBean.java

A single-line change fixes the immutable builder assignment bug:

// Before (broken)
this.builder.basePath(this.basePath);

// After (fixed)
this.builder = this.builder.basePath(this.basePath);

Both fixes come with comprehensive new tests in HttpSecuritySecurityMatchersTests and AuthorizeHttpRequestsConfigurerTests. These tests register a PathPatternRequestMatcherBuilderFactoryBean with a /spring base path, then verify that securityMatcher("/path") and securityMatchers("/path") match requests arriving at /spring/path and ignore requests arriving at just /path.

Interim Workaround

If you cannot upgrade right away, put the servlet path directly into the matcher pattern:

http
    .securityMatchers("/servlet-path/admin/**")
    //...

Identifying Vulnerable Configurations

Security teams should scan application properties for the spring.mvc.servlet.path setting. If this property is set to a value such as /api or /mvc, the application may be implicitly using the vulnerable PathPatternRequestMatcher.Builder bean and should be remediated first.

Affected Systems and Versions

This vulnerability affects only Spring Security versions 7.0.0 through 7.0.4. Spring Security 6.x and all earlier versions are not affected.

An application is vulnerable only when both of these conditions are true:

1. The application uses securityMatchers(String) to define filter chain matching.
2. A PathPatternRequestMatcher.Builder bean is published in the application context with a non-default basePath. In Spring Boot applications, this happens when spring.mvc.servlet.path is set to a custom value (e.g., /api, /mvc).

Applications that do not customize the servlet path, or that use RequestMatcher objects directly instead of string-based matchers, are not affected by this specific flaw.

Vendor Security History

The Spring project is responsive on security and ships its fixes in coordinated release trains. The April 2026 release cycle fixed five separate CVEs in Spring Security 7.0.x, all in version 7.0.5:

CVE-2026-22754 shipped alongside CVE-2026-22753, which points to a broader pattern of servlet path handling issues in the 7.0 line. Organizations upgrading to 7.0.5 should read all five advisories to see the full scope of what this release fixes.

References

• CVE-2026-22753: Servlet Path Not Correctly Included in Path Matching (Spring Advisory)
• Spring Security 2026.04 Releases (Blog Post)
• Release 7.0.5 on GitHub
• CVE-2026-22753 on NVD
• Diff: 7.0.4 to 7.0.5 on GitHub
• Spring Security Project Page
• Spring Security Advisories