Spring Security Auth Bypass Silently Kills Cloud Filters
A high-severity flaw in Spring Security 7.0.0 through 7.0.4 silently disables authentication and authorization filters when a servlet path is prepended via PathPatternRequestMatcher.Builder. Tracked as CVE-2026-22753 (CVSS 7.5), the bug means your security controls quietly stop running on targeted requests — with no crash, no error log, and no alert.
| Field | Detail |
|---|---|
| CVE | CVE-2026-22753 |
| Severity | High — CVSSv3 7.5 |
| Component | Spring Security (HttpSecurity#securityMatchers path matching) |
| Affected versions | 7.0.0 through 7.0.4 |
| Fixed version | 7.0.5 |
| Not affected | Spring Security 6.x and earlier |
| EPSS | 0.00248 (low exploit probability, KEV: not listed) |
| Advisory date | April 20, 2026 |
How the Bypass Actually Works
The vulnerability sits in one of the least-obvious corners of Spring Security 7: the interaction between string-based security matchers and the new PathPatternRequestMatcher.Builder bean. When an application calls securityMatchers(String) and uses that builder to prepend a servlet path, the framework fails to match incoming requests to the correct filter chain. The chain never executes, which means the authentication, authorization, and any custom security filters you configured for those routes simply never run.
This is not a privilege-escalation bug where an attacker crafts a payload to jump a check. It is worse than that. The check never existed for the affected requests in the first place — your HttpSecurity configuration silently stops protecting the endpoints it was meant to guard. The official Spring Security advisory classifies it as a protection-mechanism failure (CWE-693), because the intended security controls “will not be exercised as intended by the application.”
The practical consequence depends entirely on what those unguarded endpoints do. If they handle sensitive data, perform privileged operations, or expose internal services, an unauthenticated request sails straight through. There is no exploit to detect because there is nothing to exploit — the door was never locked. It is the same class of risk that made the SimpleHelp CVSS 10 OIDC auth bypass so damaging — when identity controls silently fail, attackers do not need skill, just an open endpoint.
Who Is Actually Affected
This is the part that makes CVE-2026-22753 dangerous: many Spring Boot teams will not know they are vulnerable. The triggering configuration is not an exotic, hand-rolled security setup. It is a property that looks innocuous in an application.properties or application.yml file.
According to SentinelOne’s vulnerability database and the official advisory, you are affected if your application meets all of the following conditions:
- It runs Spring Security 7.0.0 through 7.0.4 (the 7.x line only — 6.x is not impacted).
- It uses
securityMatchers(String)in its security configuration. - It configures a servlet path, most commonly via the Spring Boot property
spring.mvc.servlet.pathset to a value like/apior/mvc. - That servlet path is described through a
PathPatternRequestMatcher.Builderbean.
The fastest way to check is to grep your configuration for spring.mvc.servlet.path. If it is present and you are on Spring Security 7.0.x below 7.0.5, treat the affected endpoints as unauthenticated until you patch. If you are not using securityMatchers(String), or you are not configuring a servlet path at all, you are not in scope — but verify rather than assume, because Spring Boot auto-configuration can introduce beans transitively.
Why This Flaw Evades Detection
Security teams are trained to look for attacks: anomalies, exploit attempts, unexpected payloads in logs. CVE-2026-22753 produces none of these. Requests succeed normally, return valid responses, and leave no trace that a filter was supposed to run and did not. Your WAF sees normal traffic. Your SIEM sees nothing suspicious. Your application logs look healthy.
The only reliable signal is the absence of something that should be there — authentication records for endpoints that should require them. Most teams do not audit for the non-execution of a security filter. That blind spot is precisely what makes this class of bug valuable to a patient adversary: no exploit needed, no detection trigger, and the window stays open until a version upgrade happens to close it.
Vulmon currently scores the EPSS at 0.00248 and the CVE is not on the CISA Known Exploited Vulnerabilities catalog. That low probability cuts both ways — it reflects the lack of observed mass exploitation today, but it also means the flaw is far less likely to be on a SOC’s priority patch list, extending the window for the teams that never noticed they were exposed.
Patch and Mitigation Steps
The fix is straightforward: upgrade Spring Security to 7.0.5, which is available in open source. If an immediate upgrade is not possible, the advisory recommends reviewing whether the securityMatchers(String) usage and servlet-path configuration can be restructured to avoid the broken interaction. At minimum, treat every endpoint behind the affected filter chain as if it were public-facing until the patch lands.
Concretely, cloud and platform teams should take these steps now:
- Inventory every Spring Boot 7.x service. Identify which set
spring.mvc.servlet.pathand usesecurityMatchers(String). - Triage the business impact of each exposed endpoint. Prioritise anything handling credentials, payment data, internal APIs, or admin functions.
- Patch to Spring Security 7.0.5 in your next deploy window — or hotfix if sensitive endpoints are confirmed exposed.
- Verify post-patch by sending unauthenticated requests to previously affected endpoints and confirming they are rejected as expected.
- Backfill detection by alerting on successful unauthenticated access to endpoints that should require auth, so this failure mode never goes unnoticed again.
Spring’s Advisory Volume Just Spiked 1,766%
CVE-2026-22753 does not exist in isolation. It landed as part of an April 2026 Spring Security update that fixed seven CVEs, including two critical authorization bypasses, as HeroDevs documented. Behind that batch is a trend that should worry anyone running Java in production.
In its June 2026 release, Broadcom’s Tanzu division — the steward of Spring, a framework relied on by over half of Fortune 500 companies — shipped what it called the largest single set of Spring security updates in the framework’s 23-year history. The driver, according to a Tanzu blog post dated June 9, 2026, was “an unprecedented surge in AI-detected security threats,” making any systemic weakness in the framework a cloud-scale exposure.
The numbers are stark. The same Tanzu post reported a 1,766% monthly increase in Spring security advisories from the community in April 2026 alone, with elevated volumes continuing into May. The company’s assessment is blunt: “Malicious actors can now use AI to build effective exploits in hours, rather than days or weeks.” The patching window — already shrinking for years — has effectively collapsed. We have already watched AI tools surface RCE-grade flaws that human auditors missed for years, as with the OpenSSL PKCS7_verify bug; the same offensive capability is now compounding the advisory volume Broadcom is racing to patch.
Broadcom’s response is commercial as much as technical. It is now offering CVE-only patches and backports to Tanzu Spring customers, including Spring Boot 3.5 support through 2032, plus an SLSA Level 3–validated software supply chain built on the clean-room architecture behind Bitnami. The subtext is clear: free, volunteer-paced open-source patching is no longer fast enough for the threat curve, and vendors are selling speed as the differentiator.
What Cloud Teams Should Do Now
The strategic lesson from CVE-2026-22753 is not about one CVE — it is about a failure mode that the current advisory volume makes routine. When a framework ships the largest security update in its history and the underlying advisory count has grown nearly eighteen-fold in a month, “patch when convenient” is no longer a viable policy.
For teams running Spring in the cloud, three shifts are overdue. First, move to continuous dependency monitoring with automated CVE alerting on the Spring components in every service — manual triage cannot keep pace. Second, treat protection-mechanism failures (CWE-693) as a distinct detection category: build assertions that security filters actually execute, not just that the application runs. The same blind spot bit teams in the SAP NetWeaver SAML spoofing flaws, where trust assumptions in the identity layer went unverified. Third, close the gap between advisory publication and deployment with a rapid-patch pipeline for high-severity framework CVEs, so that a silent bypass like this one is remediated in hours, not the weeks it takes a backlog-bound team to reach it.
The flaw is subtle. The fix is simple. The cost of missing it is that your authentication was never running — and nothing told you so.