CVE-2026-59354: Spring Security OAuth2 Authorization Server Dynamic Client Registration Flaw

Overview

Spring has disclosed a critical vulnerability in Spring Security's OAuth2 Authorization Server module, tracked as CVE-2026-59354 (CVSS 9.6). When an application explicitly enables Dynamic Client Registration (DCR), the registration endpoint fails to sufficiently validate certain client metadata fields supplied by the registering party.

An attacker who holds a valid Initial Access Token — the credential DCR uses to gate who may register a new OAuth2 client — can submit crafted metadata during registration. Depending on how the deploying application consumes that metadata downstream, this can result in stored Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), or privilege escalation. Researcher Kelvin Mbogo is credited with the responsible disclosure.

Technical Details

How It Works

Spring Security's Authorization Server supports RFC 7591 Dynamic Client Registration, letting OAuth2 clients self-register rather than requiring an administrator to provision them manually. This is gated behind an Initial Access Token — a credential intended to restrict registration to trusted callers.

The flaw is that once a caller presents a valid token, the registration endpoint does not sufficiently validate the client metadata fields it accepts (for example, redirect URIs, client name, or logo/JWKS URIs). Because that metadata is later rendered in admin consoles, used to construct outbound requests, or trusted for authorization decisions in some deployments, an attacker-controlled value can be weaponized into stored XSS, SSRF, or privilege escalation — the specific outcome depends on how the application built on top of the authorization server consumes the registered metadata.

Impact

• Stored XSS — malicious client metadata rendered in an admin or client-management UI can execute in the context of an administrator's session
• SSRF — metadata fields that get fetched or dereferenced server-side (e.g., JWKS URI, logo URI) can be pointed at internal infrastructure
• Privilege escalation — insufficiently validated metadata used in authorization decisions could let a registered client claim capabilities it shouldn't have
• The Initial Access Token requirement limits this to semi-trusted callers — but any deployment that issues these tokens broadly (self-service developer portals, multi-tenant platforms) is meaningfully exposed

Remediation

• Upgrade to Spring Security 7.0.5 or later. Per the vendor advisory, no further mitigation is necessary once patched
• Until patched, restrict issuance of Initial Access Tokens to fully trusted parties only
• Audit dynamically registered clients for suspicious metadata (unexpected redirect URIs, external logo/JWKS hosts) and review any recently onboarded clients
• If DCR is not actively required, disable it until the upgrade is applied

References

• Spring Security Advisory — CVE-2026-59354
• NVD — CVE-2026-59354