CVE-2026–22752. A Valid Token Is All It Takes. Then the OAuth Layer Becomes the Attack Surface.

CVE-2026–22752 does not require an unauthenticated attacker. It requires one with a valid Initial Access Token — a bar that is lower than it sounds in environments where token issuance is broad, where developer or test tokens persist beyond their intended lifespan, or where a prior credential exposure has gone undetected.

From that starting position, the vulnerability allows an attacker to register a malicious OAuth client through Spring Authorization Server's Dynamic Client Registration endpoint. What follows is a cascade: Stored XSS injectable into the authorization server's administrative interface, privilege escalation within the OAuth trust boundary, and SSRF against internal infrastructure reachable from the authorization server's network position. The CVSS vector is network-exploitable and low-complexity. The affected versions span Spring Security 7.0.0 through 7.0.4 and Spring Authorization Server 1.3.0 through 1.3.10, 1.4.0 through 1.4.9, and 1.5.0 through 1.5.6.

Why the OAuth Position Matters

Authorization servers sit at a structurally sensitive point in microservice architectures. They issue and validate the tokens that other services use to make trust decisions. An attacker who can register a malicious OAuth client through Dynamic Client Registration does not simply compromise the authorization server — they insert themselves into the trust chain that every downstream service relies on.

Stored XSS in the administrative interface creates a persistent attack surface against whoever administers the authorization server. SSRF from the authorization server's network context is particularly damaging because that server is typically positioned with internal network access — it needs to reach identity providers, user directories, and downstream services. An attacker using SSRF from this position is not pivoting from a low-privilege host. They are pivoting from one of the more trusted network positions in the environment.

The privilege escalation component connects both. A malicious OAuth client registered with elevated scopes can request tokens that grant access to resources the attacker was never authorised to reach.

Defender Actions

• Upgrade immediately to Spring Security 7.0.5, Spring Authorization Server 1.3.11, 1.4.10, or 1.5.7 — patch availability removes the justification for delay on a low-complexity, network-exploitable vulnerability
• If immediate upgrade is not possible, disable Dynamic Client Registration as a temporary mitigation — this removes the endpoint through which the malicious client registration occurs
• Audit all currently registered OAuth clients for unexpected entries, unfamiliar redirect URIs, or clients with scopes inconsistent with their stated purpose
• Review Initial Access Token issuance policies — restrict who can obtain tokens, enforce expiry, and revoke any tokens issued during the affected version window that cannot be accounted for
• In SIEM, alert on new OAuth client registrations, particularly outside business hours or from unexpected source IPs, and on outbound connections from the authorization server process to internal network ranges not consistent with its normal function
• Treat your authorization server's network egress as a monitored boundary — SSRF exploitation will appear as unexpected internal connections originating from a host that normally has a predictable and narrow connection profile

The token was valid. The client registration was not.