CVE-2021-22112 is a privilege-escalation vulnerability in Spring Security, the authentication and access-control framework underpinning most enterprise Java applications, including those built on Spring Security OAuth2 for resource servers and authorization servers. The bug centers on improper authorization: under a specific sequencing of events, Spring Security can fail to persist an updated SecurityContext to the HttpSession, which means a security decision made for one narrow part of a request can silently remain in effect for the rest of a user's session. In plain terms, an application that briefly elevates a user's privileges for a single operation can end up leaving that user permanently elevated — a textbook improper authorization outcome, and exactly the kind of state-management bug that security researchers watch for in any Spring Security OAuth2 deployment where authorization decisions hinge on session state.
The vulnerability was disclosed by the Spring team on February 19, 2021, alongside a matching Jenkins security advisory, since Jenkins core embeds Spring Security and was directly affected. It's a good reminder that "improper authorization" bugs don't require an attacker to send anything malicious — they can live entirely inside how a framework manages authorization state internally, which is precisely why supply chain visibility into transitive dependency versions matters as much as scanning your own code.
What Went Wrong
Spring Security enforces authorization using a SecurityContext object that holds the current Authentication — the identity and granted authorities for the request. The SecurityContextPersistenceFilter is responsible for loading that context at the start of a request and saving it back to the HttpSession once the filter chain finishes.
The flaw appears when application or framework code changes the SecurityContext more than once within a single request, specifically when: the context is changed once before the HttpServletResponse is committed, the response then commits before SecurityContextPersistenceFilter completes its work, and the context is changed again before that filter finishes. In that sequence, the final, correct SecurityContext can fail to be written back to the session — meaning whatever elevated state existed on that request can persist into subsequent requests, well past its intended scope.
Spring's advisory is careful to note that a malicious user cannot trigger this bug on their own; it has to be built into how an application (or a framework built on top of Spring Security) manages temporary privilege changes — for example, "run-as" or impersonation patterns, or any custom filter that swaps the authenticated principal mid-request for a scoped operation. If your application does that anywhere in a Spring Security OAuth2 authorization or resource-server chain, the result is the same improper authorization failure mode: privileges meant to be scoped to a slice of the request instead leak into everything that follows.
Affected Versions and Components
CVE-2021-22112 affects the following Spring Security releases (distributed via spring-security-core, spring-security-web, and the spring-security-bom):
- 5.4.0 through 5.4.3
- 5.3.0.RELEASE through 5.3.7.RELEASE
- 5.2.0.RELEASE through 5.2.8.RELEASE
- Older, unsupported 5.x and earlier lines
Because Spring Security OAuth2 support, Spring Boot's actuator security auto-configuration, and Spring Cloud Gateway's security filters all sit on top of spring-security-core's SecurityContext machinery, any downstream project pinning one of these vulnerable core versions inherits the exposure — regardless of whether OAuth2, actuator, SAML, or plain form login is the front-line authentication mechanism. Jenkins is the clearest real-world case: versions 2.266 through 2.279 bundled a vulnerable Spring Security release, and in the 2.275–2.278 window, users holding only Job/Workspace permission could exploit the pattern to have their session's authorization state escalate to the internal SYSTEM user — full administrative equivalence — without ever touching an admin credential.
Fixed versions: Spring Security 5.2.9, 5.3.8, and 5.4.4 resolve the issue. Jenkins shipped the fix in core 2.280, which bundled the patched Spring Security release.
CVSS, EPSS, and KEV Context
There's a notable split in how this CVE is scored. Spring's own advisory rates the issue Low severity, reflecting that exploitation depends entirely on an application's own use of the framework rather than anything an outside attacker can trigger directly. NVD and downstream advisory databases (including GitHub Security Advisories), however, score the underlying weakness itself — improper privilege management (CWE-269) — at a CVSS v3.1 base score of 8.8 (High), vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, reflecting the worst-case impact if an application does contain the vulnerable pattern (as Jenkins did).
That gap between vendor-assessed and CVSS-scored severity is a useful case study in why raw CVSS alone shouldn't drive prioritization: the ceiling of impact is high, but the likelihood depends on whether your specific application logic changes the SecurityContext more than once per request. EPSS, which estimates real-world exploitation probability, puts CVE-2021-22112 at roughly a 3% predicted exploitation likelihood in the near term — modest in absolute terms, though it lands around the 86th percentile relative to the broader CVE population, meaning most other vulnerabilities are predicted to be exploited even less often. As of this writing, CVE-2021-22112 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, so there's no confirmed record of in-the-wild exploitation — the Jenkins impact was disclosed responsibly, not discovered through an active incident.
Timeline
- Discovery: Reported to the Spring and Jenkins security teams by Daniel Beck, Jeff Thompson, Jesse Glick, and Wadeck Follonier of CloudBees, Inc., after identifying the impersonation/SYSTEM-escalation path in Jenkins.
- February 19, 2021: Spring publishes the CVE-2021-22112 advisory alongside patched releases; Jenkins publishes a coordinated security advisory for the same date, detailing the SYSTEM-privilege-escalation impact in Jenkins core.
- Remediation availability: Spring Security 5.2.9, 5.3.8, and 5.4.4 released as the fixed versions; Jenkins 2.280 ships bundling the patched dependency.
- Ongoing: The CVE continues to surface in dependency and SBOM scans of legacy Java services still pinned to pre-2021 Spring Security releases, and in Jenkins instances that have never been upgraded past the 2.279 line.
Remediation Steps
- Identify exposure across your dependency tree. Don't just check your application's declared
spring-security-*version — check transitive pulls through Spring Boot starters, Spring Cloud, and any embedded servers (like Jenkins agents or plugins) that vendor their own copy of Spring Security. - Upgrade to a fixed release. Move to Spring Security 5.2.9, 5.3.8, 5.4.4, or later (the current supported line is safest long-term). Jenkins users should upgrade core to 2.280 or later.
- Audit any mid-request
SecurityContextmutation. If your application implements impersonation, "run-as," delegated authorization, or custom filters that callSecurityContextHolder.setContext()more than once per request — including inside custom OAuth2 token exchange or scope-elevation logic — review that code path specifically, since it's the mechanism that turns this bug from theoretical to exploitable. - Re-test session and authorization boundaries after upgrading. Confirm that privilege elevation used for a single operation (e.g., a scoped admin action) does not persist into unrelated subsequent requests in the same session.
- Pin and monitor going forward. Add
spring-security-core/spring-security-webversion constraints to your build, and alert on any transitive resolution that drifts back into the vulnerable ranges (pre-5.2.9, 5.3.0–5.3.7, 5.4.0–5.4.3).
How Safeguard Helps
CVE-2021-22112 is a good illustration of why point-in-time dependency checks aren't enough: the vulnerable version ranges span multiple minor lines, the framework is buried several layers deep in most build graphs (Spring Boot starters, Spring Cloud, CI/CD tooling like Jenkins itself), and the real risk depends on application-specific usage patterns that a version number alone can't reveal.
Safeguard's software supply chain security platform is built for exactly this kind of layered exposure. Continuous SBOM generation and dependency graph analysis surface every instance of spring-security-core, spring-security-web, and related artifacts across your services — including transitive pulls hidden inside build tooling and CI infrastructure like Jenkins — and flag any version falling inside the CVE-2021-22112 affected ranges before it ships to production. Policy gates in the CI/CD pipeline can block builds that pin a vulnerable Spring Security version, while drift detection alerts your team if a dependency resolution silently reintroduces one of the affected releases during a later build.
Because Safeguard correlates CVSS, EPSS, and KEV signals rather than surfacing CVSS in isolation, teams get the same nuance this analysis relies on: a High CVSS score paired with a modest EPSS likelihood and no KEV listing should be triaged differently than a High-severity, actively-exploited flaw — and Safeguard's prioritization reflects that instead of forcing every "High" finding through the same urgent-patch workflow. For services where a fast framework upgrade isn't immediately possible, Safeguard's exposure tracking helps teams identify which applications actually implement mid-request privilege-elevation patterns, so remediation effort goes first to the deployments where the theoretical impact of CVE-2021-22112 is most likely to be real.