CVE-2026-22752: Spring Authorization Server Critical — XSS, SSRF, and Privilege Escalation
How a flaw in dynamic client registration exposes OAuth servers to XSS, SSRF, and token abuse.
Spring Authorization Server is the Spring ecosystem's OAuth 2.1 and OpenID Connect authorization server. It runs as the OAuth backbone for internal SSO platforms, B2B SaaS APIs, developer portals, and multi-tenant OAuth providers. Its optional Dynamic Client Registration (DCR) endpoint lets external parties register new OAuth clients at runtime using an Initial Access Token. That capability, when enabled, is exactly where CVE-2026-22752 lives.
The bug is insufficient validation of client metadata on the DCR endpoint. An attacker holding a valid Initial Access Token can register a client with crafted metadata: a javascript:, data:, or vbscript: URI in redirect_uris or post_logout_redirect_uris; an http://* jwks_uri pointed at an internal or cloud-metadata host; or unauthorized values in scope. Depending on the field abused, the outcome is XSS fired when the authorization server hands the registered URI back to the browser during the OAuth flow, SSRF from the authorization server's network position when it fetches the JWKS, or scope escalation against downstream resource servers via tokens issued to the attacker's client. The Spring Security Advisory has this vector string listed: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N; making it a 9.6 Critical.
Spring shipped fixes on April 21, 2026, but only partially in the open. Spring Security 7.0.5 and Spring Authorization Server 1.5.7 are available in OSS. The 1.2.x, 1.3.x, and 1.4.x are vulnerable and are not in OSS support. For teams on 1.3.x or 1.4.x without a Tanzu contract, there is no free remediation path.
Spring's advisory scopes only the versions they support at some tier. Spring Authorization Server 1.2.x doesn’t appear in the advisory at all, even though it is affected. Spring does not acknowledge the exposure because version 1.2 is no longer in commercial support. Teams running those versions with DCR enabled are vulnerable with no vendor-provided remediation path of any kind.
TL;DR
Who is affected
As of Spring Security 7.x, Spring Authorization Server has been integrated directly into Spring Security. This is why the vulnerability affects both the standalone Spring Authorization Server 1.x releases (which correspond to Spring Security 6.x) and Spring Security 7.x.
You are only exposed if Dynamic Client Registration is explicitly enabled. DCR is off by default. Grep your Spring Security configuration for oidc().clientRegistrationEndpoint() or OidcClientRegistrationEndpointConfigurer. If neither is present, DCR is off and this CVE does not apply.
The enabled population is narrow but operationally significant. DCR is turned on for exactly the deployments where a compromised client does the most damage: multi-tenant B2B SaaS platforms that let customers self-onboard OAuth clients, developer portals where partners register integrations without manual approval, internal platform-as-a-service tenants that provision scoped client credentials automatically.
Exposure Spring Boot starters and internal BOMs can pull in an affected version without an explicit declaration. Teams inheriting DCR configuration from a shared platform module may have it enabled without realizing it.
What the vulnerability actually does
A Dynamic Client Registration request is a POST to the registration endpoint carrying a JSON payload of client metadata: redirect_uris, post_logout_redirect_uris, jwks_uri, scope,, and others. The server validates this payload, persists the client, and returns a registration_access_token the client uses later. Validation of certain of these fields is insufficient. The three documented outcomes map cleanly onto known DCR attack classes.
Detection guidance
- Check whether DCR is enabled. Grep for oidc().clientRegistrationEndpoint() or OidcClientRegistrationEndpointConfigurer in your Spring Security configuration. If absent, DCR is off.
- Check who holds tokens with client.create scope. That population is the exploit surface.
- Check your classpath. mvn dependency:tree against the affected ranges above.
- Audit existing client registrations. Look for redirect_uris or post_logout_redirect_uris using non-http(s) schemes (javascript:, data:, vbscript:) or protocol-relative URIs, inspect jwks_uri values using http:// and any registered clients carrying unexpected scope claims.
Remediation
If you are on a supported Spring Authorization Server branch
Upgrade to Spring Authorization Server 1.5.7 or Spring Security 7.0.5, matched to your Spring Boot version. Both are on Maven Central. Run regression coverage on the DCR acceptance path: redirect_uris and post_logout_redirect_uris now reject fragment, missing-scheme, and javascript:/data:/vbscript: schemes; jwks_uri must be https; and scope is rejected by default on DCR. If your deployment previously relied on accepting scope at registration time, you will need to restore that behavior explicitly. See Spring's reference configuration for the supported pattern.
If you are running Spring Authorization Server 1.2.x, 1.3.x, or 1.4.x
The fixes for 1.3.x and 1.4.x ship only in 1.3.11 and 1.4.10, distributed through an enterprise support subscription. Remediation for 1.2 is only available through HeroDevs NES. They are not on Maven Central. Two options:
- Upgrade to Spring Authorization Server 1.5.x (OSS). 1.5.7 has the fix in the open. The move requires a Spring Boot 3.5-compatible baseline, which for teams on Spring Boot 3.3 (Spring Authorization Server 1.3.x) or 3.4 (Spring Authorization Server 1.4.x) is a multi-sprint project: dependency reconciliation, deprecation review, regression coverage on OAuth flows.
- HeroDevs NES for Spring. NES delivers remediated Spring Authorization Server packages at the original Maven coordinates via a token-authenticated private registry. For teams who need to close CVE-2026-22752 without the Spring Boot 4.0 migration, NES is the drop-in fix at the version you are already running.
Migration is a multi-sprint project, not a hotfix.
Frequently asked questions about CVE-2026-22752
Which versions are affected? Spring Security 7.0.0 through 7.0.4. Spring Authorization Server 1.2.0 through 1.2.7, 1.3.0 through 1.3.10, 1.4.0 through 1.4.9, and 1.5.0 through 1.5.6. Fix versions are Spring Security 7.0.5, SAS 1.5.7 (both OSS).
DCR is off by default. Am I affected? Only if you explicitly enabled it. If oidc().clientRegistrationEndpoint() is not configured, the endpoint is not exposed. Confirm your actual runtime configuration rather than assuming, especially if DCR could be enabled through an inherited Spring Boot starter or a shared platform module.
Our DCR endpoint requires an Initial Access Token. Isn't that enough? The token is the authentication boundary. It authorizes the caller to register a client. It does not validate the metadata the caller supplies. The vulnerability is in the metadata validation path, which runs after authentication. Any token holder who should be able to register a client can exploit this CVE.
I'm on Spring Authorization Server 1.2/1.3/1.4. Why is there no OSS fix? Spring Authorization Server 1.2/1.3/1.4 all have transitioned out of OSS maintenance. The 1.4.10 release carrying the CVE-2026-22752 fix is published only through Tanzu Spring Enterprise. The same applies to 1.3.x and 1.3.11. For teams not on Tanzu Spring Enterprise, the OSS options are migrating to 1.5.x or running a commercially supported drop-in like HeroDevs NES.
How does this affect SOC 2, PCI DSS, or FedRAMP compliance? CVSS score of 9.6 has been declared as Critical. This published advisory starts a remediation-window clock. PCI DSS 6.3.3 requires critical patches within one month. SOC 2 CC7.1 and FedRAMP High carry similar timelines. For teams on 1.2.x, 1.3.x, or 1.4.x without a commercial support contract, even if you upgrade to 1.5 you only have 1 month of OSS support. Closing the finding within the audit window typically requires either a commercial fix channel (Tanzu Spring Enterprise or HeroDevs NES).
Taking action
If you are on Spring Security 7.0.x or Spring Authorization Server 1.5.x, upgrade to 7.0.5 or 1.5.7 from Maven Central. Done.
If you are on Spring Authorization Server 1.2.x, 1.3.x, or 1.4.x, the OSS fix does not exist at those coordinates. Because there is no upstream OSS patch path, any exposed deployment on 1.2.x, 1.3.x, or 1.4.x remains vulnerable indefinitely without either a commercial support contract or a migration to 1.5.x. The 1.5.x migration is a Spring Boot 3.5 upgrade project, not a hotfix.
HeroDevs NES for Spring delivers remediated Spring Authorization Server packages at the original Maven coordinates as a drop-in fix. If you need to close this finding now, that is the path.
Talk to HeroDevs about NES for Spring
Related:
