Spring Security OAuth2 client vulnerability (CVE-2022-31690)

Spring Security's OAuth2 Client module carries a privilege-escalation flaw tracked as CVE-2022-31690, disclosed by VMware/Spring in a security advisory (GHSA-9xh3-2gvw-fh76) in August 2022. In multi-tenant applications that rely on the framework's default client_credentials or refresh_token grant handling, the vulnerability can allow an authenticated user to end up in possession of an OAuth2 access token that was actually issued for a different principal or client registration. In a system where OAuth2 tokens are used to scope access to downstream APIs, tenant data, or backend services, that kind of token confusion translates directly into unauthorized data access or privilege escalation — one user effectively borrowing another's authorization context.

This post breaks down what's affected, how severe the issue is, what the disclosure timeline looked like, and — most importantly — the concrete steps engineering and security teams should take to close it out. We close with how Safeguard helps teams find, prioritize, and fix issues like this one before they become incidents.

What's Affected

CVE-2022-31690 lives in spring-security-oauth2-client, the module Spring Security applications use to act as an OAuth2 client (as opposed to an authorization server or resource server). The affected code paths are the default OAuth2AuthorizedClientProvider implementations that back the client_credentials and refresh_token grant types, along with the authorized-client caching layer that stores and retrieves tokens by principal.

According to Spring's advisory, the following versions are affected:

• Spring Security 5.7.x prior to 5.7.5
• Spring Security 5.6.x prior to 5.6.9
• Older, unsupported 5.x branches (5.5.x and earlier), which never received a backport

Because spring-security-oauth2-client is frequently pulled in transitively through spring-boot-starter-oauth2-client, teams should not assume they're unaffected just because they don't declare the artifact directly. Any Spring Boot service that authenticates to downstream APIs or authorization servers using OAuth2 client credentials, resource-owner password, or refresh-token grants — a common pattern for service-to-service auth and multi-tenant SaaS backends — is a candidate for review.

It's worth being precise about what is not affected: this CVE concerns the client-side authorized-client management layer, not the OAuth2 login/authorization-code flow used for interactive user sign-in, and it's a distinct issue from CVE-2022-31692 (a separate Spring Security advisory from the same disclosure window involving authorization bypass via forward/include dispatch types). The two are easy to conflate in vulnerability reports because they landed close together, but they have different root causes and different fixes.

Severity: CVSS, EPSS, and KEV Context

Spring's advisory assigns CVE-2022-31690 a CVSS v3.1 base score of 8.1 (High), reflecting a network-exploitable vector with no privileges required by the attacker but with confidentiality and integrity impact rated high — consistent with an authenticated user gaining access to a token or resource scope that isn't theirs.

For prioritization purposes, two additional signals matter:

• EPSS (Exploit Prediction Scoring System): As of this writing, CVE-2022-31690's EPSS score is low — well under 1% — indicating no significant observed or predicted exploitation activity in the wild. This is typical for library-level authorization logic flaws that require a specific application architecture (multi-tenant client-credential reuse) to be exploitable, rather than a generic remote-code-execution primitive.
• CISA KEV: CVE-2022-31690 does not appear in CISA's Known Exploited Vulnerabilities catalog.

The combination of a high CVSS score with low EPSS and no KEV listing is a common pattern for this class of vulnerability, and it's exactly the kind of nuance that a CVSS-only prioritization model misses. A high base score signals real potential impact if your architecture matches the vulnerable pattern, but the absence of active exploitation means teams can — and should — prioritize based on actual exposure (do you use these grant types in a multi-tenant context?) rather than treating every 8.1 as a fire drill. This is precisely where reachability analysis earns its keep, and we'll come back to that below.

Timeline

• Prior to August 2022: Issue identified in Spring Security's OAuth2 Client authorized-client provider and caching logic.
• August 24–25, 2022: VMware/Spring published the security advisory alongside patched releases; CVE-2022-31690 was assigned and subsequently synced to NVD.
• Fixed versions released: Spring Security 5.6.9 and 5.7.5 (and later 5.6.x/5.7.x patch releases, plus all subsequent minor versions such as 5.8.x and 6.x, which incorporate the fix).
• Since 2022: No confirmed reports of in-the-wild exploitation have surfaced publicly, consistent with the low EPSS score, but the flaw remains present in any application still running unpatched dependency versions — which, given how transitive dependency drift works, is more common than teams expect.

Remediation Steps

1. Identify affected services. Inventory every service that depends on spring-security-oauth2-client, whether directly or transitively via spring-boot-starter-oauth2-client. Don't rely on manual grep-through-pom.xml audits at scale — use dependency-tree resolution (mvn dependency:tree / ./gradlew dependencies) or an SBOM-backed inventory to catch indirect inclusions across microservices.

2. Upgrade the dependency. Move to Spring Security 5.6.9+ or 5.7.5+, or — preferably — the latest supported Spring Security/Spring Boot release line, since 5.6.x and 5.7.x are both now outside their support windows. If you manage versions via the Spring Boot BOM, bumping the Boot parent version is usually sufficient; verify the resolved spring-security-oauth2-client version explicitly rather than assuming the BOM bump pulled in the fix.

3. Audit custom OAuth2AuthorizedClientProvider and OAuth2AuthorizedClientService implementations. If your application overrides Spring's defaults with custom logic, confirm that authorized-client lookups and caching are keyed correctly on principal identity and client registration ID together, not just one or the other, to prevent cross-principal token bleed.

4. Rotate credentials where exposure can't be ruled out. If the affected code paths were in production use with multi-tenant client-credential or refresh-token flows, treat any tokens issued during the exposure window as potentially compromised and rotate client secrets and refresh tokens as a precaution.

5. Add regression coverage. Write an integration test that exercises the client-credentials/refresh-token flow with two distinct principals concurrently and asserts that each receives only its own token — this both validates the fix and guards against regression if custom provider logic is reintroduced later.

6. Wire this into continuous SCA. One-time patching doesn't prevent the next transitive-dependency regression. Continuous software composition analysis against your manifests and lockfiles, tied to an SBOM, is what catches the next Spring Security advisory before it ships to production.

How Safeguard Helps

Patching a CVE like this across dozens of Spring Boot services is straightforward in theory and messy in practice — the hard part is knowing which services actually invoke the vulnerable client_credentials/refresh_token code paths in a multi-tenant configuration, versus which ones merely have the dependency on the classpath without ever calling it. Safeguard's reachability analysis traces actual call paths from your application code into spring-security-oauth2-client's authorized-client providers, so teams can separate "must patch now" from "patch on the normal cadence" instead of treating every instance of the dependency as equally urgent. Griffin, Safeguard's AI-powered analysis engine, correlates that reachability signal with your deployment context to explain why a given service is or isn't exposed, in plain language a reviewer can act on without reading the Spring advisory line by line. Safeguard's SBOM generation and ingestion capabilities give you a standing inventory of exactly where spring-security-oauth2-client — and every other transitive dependency — appears across your services, so the next Spring Security advisory doesn't require an ad hoc grep-and-pray audit. And when a fix is confirmed, Safeguard can open auto-fix pull requests that bump the affected dependency to a patched version directly in your repos, cutting the time from advisory to remediated code from days to minutes.