Imagine putting a lock on your front door, only to discover the lock was never actually connected to anything — and every stranger who tried the handle just walked right in.
Who's at Risk — and How Many People Does This Touch?
Spring Security is one of the most widely deployed security frameworks in the world. It sits quietly inside the backend of banking portals, healthcare patient dashboards, government services, e-commerce checkout systems, and enterprise HR platforms. Hundreds of thousands of Java-based web applications rely on it to decide who can see what. If your company runs Java on the backend — and a staggering number do — there is a meaningful chance this vulnerability is sitting in your infrastructure right now.
The affected versions run from Spring Security 7.0.0 through 7.0.4, a release range that spans the entirety of the framework's 7.x generation. That means any organization that adopted the latest major version since its release, believing they were on the most current and secure codebase, is potentially exposed. The flaw carries a CVSS score of 7.5, rated HIGH — serious enough that security teams should treat it as urgent, not a "patch it next sprint" situation.
What's Actually Happening — No Jargon, Just the Story
Think of a web application like a building with many rooms. Some rooms are public — anyone can walk in. Others are restricted — you need a badge, a password, a verified identity. The security team writes rules that say: "Anyone trying to reach the executive suite on the third floor must show credentials." In Spring Security, developers write those rules in configuration files, specifying exactly which web addresses (paths) require which level of permission. It's supposed to be airtight.
The bug in CVE-2026-22754 breaks that system in a specific but devastating way. When developers use a particular configuration style to define a sub-section of their application — essentially saying "these rules apply to everything under this specific part of the site" — the framework quietly forgets to include that sub-section label when it checks incoming requests. The result: a request arrives at a protected address, the security system looks up its rules, finds no matching rules (because the path was calculated wrong), and simply... lets the request through. No badge check. No identity verification. The door swings open.
An attacker doesn't need to be sophisticated to exploit this. They don't need to break any encryption or guess any passwords. They simply need to know — or guess — that a protected endpoint exists, then send a request to it. If the vulnerable configuration is in place, the app's own security framework waves them in. Sensitive data, administrative functions, private user records — whatever lives behind that door is now exposed to anyone who tries the handle.
The Technical Detail That Matters
For security researchers and engineers who want the precise failure point: the vulnerability lives in how Spring Security processes the <sec:intercept-url> tag when the servlet-path attribute is used to scope authorization rules. During path-matching computation, the framework strips the servlet path prefix before evaluating the configured patterns — meaning the effective authorization rules are never exercised against requests that match that prefix. This is a classic authorization bypass via path-matching miscalculation, functionally similar in impact to path traversal vulnerabilities, though the mechanism is configuration-layer logic failure rather than input manipulation. CVSS 7.5 (HIGH), network-exploitable, no authentication required, no user interaction required.
Has Anyone Been Attacked Yet?
As of publication, there is no confirmed evidence of active exploitation in the wild. No threat actor groups have been publicly linked to campaigns targeting this vulnerability, and no known victims have been reported. However, the security community's experience with authorization bypass flaws in popular frameworks is consistent and sobering: the window between public disclosure and active exploitation is shrinking. When a vulnerability requires no special tools, no credentials, and no victim interaction — just knowledge of the flaw and a web request — it tends to get weaponized quickly.
The vulnerability was disclosed through VMware Broadcom's official Spring Security security advisory channel. At this time, no third-party researcher attribution has been publicly confirmed. Organizations using Spring Security 7.0.x should assume that motivated attackers are already studying this disclosure.
What You Should Do Right Now
Three specific steps, in priority order:
-
Upgrade to Spring Security 7.0.5 or later immediately. This is the patched release that corrects the servlet-path calculation logic. If your team is on a version between 7.0.0 and 7.0.4, there is no partial mitigation — you need the patch. Check your
pom.xmlorbuild.gradlefor thespring-security-webandspring-security-configdependency versions and update both together. If you use Spring Boot, update to the Spring Boot release that bundles Spring Security 7.0.5+ and verify the resolved version in your dependency tree. -
Audit your security configuration files for
servlet-pathusage right now — before the patch ships. Search your codebase for any<sec:intercept-url>tags that include theservlet-pathattribute. For each one, manually verify what endpoints those rules are meant to protect and assume those protections are currently non-functional. Consider temporarily adding application-layer checks (input validation, session verification in controller logic) as a stopgap for your most sensitive endpoints until the patch is deployed. - Enable detailed access logging and alert on unexpected access to sensitive paths. Even if you patch quickly, it's worth knowing whether someone already walked through that open door. Configure your web server or application server to log all requests to paths that should have been protected by the affected rules. Review those logs going back to when your application first deployed Spring Security 7.0.x. Flag any access from unexpected IP addresses, unusual user agents, or unauthenticated sessions. If you use a WAF or SIEM, create a temporary rule to alert on access to those endpoints in real time.
CVE: CVE-2026-22754 | CVSS: 7.5 HIGH | Affected: Spring Security 7.0.0 – 7.0.4 | Fixed in: Spring Security 7.0.5 | Exploitation: None confirmed