Spring Authorization Server CVE-2026-59316

The vulnerable code path is activated only when the application uses Spring Authorization Server's DefaultConsentPage; deployments that have implemented any custom consent page are entirely unaffected. An attacker must be able to submit an OAuth2 authorization request to the server - for public-facing authorization servers this typically requires no authentication, consistent with the PR:N CVSS metric. Exploitation additionally requires that a legitimate user be directed through the OAuth2 consent flow and view the consent page after the malicious request has been stored, satisfying the UI:R constraint. Limiting factors: requiring pre-authenticated users before reaching the consent page, restricting OAuth2 client registration, or deploying a custom consent UI each independently reduce or eliminate the attack surface beyond what the raw CVSS score conveys.

The CVSS 3.1 score of 8.2 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N) accurately models the attack surface: no authentication or special network position is required to plant the payload, complexity is low, and the scope change (S:C) reflects JavaScript execution in the victim's browser rather than the server process itself. The primary practical constraint is UI:R - the victim must actively proceed through an OAuth2 authorization flow and view the consent page, limiting opportunistic mass exploitation. EPSS probability data is absent from available intelligence, and the vulnerability does not appear on the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis; no public proof-of-concept code has been identified. Real-world risk is sharply conditioned on DefaultConsentPage usage - organizations that have deployed a custom consent UI are entirely unaffected. Despite the absence of active exploitation signals, the trivial injection mechanics combined with the high confidentiality impact (enabling session token and credential theft via arbitrary script execution in the victim's browser) makes this an urgent remediation priority wherever affected versions and the default consent page coexist.

An attacker registers or controls an OAuth2 client and submits an authorization request to the vulnerable Spring Authorization Server containing a scope value or client parameter embedding a malicious script payload. When a legitimate user is subsequently redirected through the consent flow, the DefaultConsentPage renders the stored payload as live HTML, causing the attacker's JavaScript to execute in the user's browser and exfiltrate their session cookie or OAuth token to an attacker-controlled endpoint. No proof-of-concept code has been identified, but the exploitation path requires no specialized tooling beyond the ability to submit HTTP requests to the authorization endpoint.