CVE-2026-59316

Overview

Spring Authorization Server is a Spring project that provides a framework for building OAuth 2.1 and OpenID Connect 1.0 authorization servers on top of Spring Security. It supplies the protocol endpoints, token issuance, consent handling, and client registration machinery an identity provider needs, and it is designed to be embedded in and customized by a Spring Boot application.

A Cross-Site Scripting (XSS) vulnerability (CVE-2026-59316) has been identified in the default consent page of Spring Authorization Server, which allows attackers to inject arbitrary HTML and script into the consent screen presented to an authenticated end user and to execute that script in the user's browser under the authorization server's origin.

Per OWASP: Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

This issue affects the built-in default consent page of Spring Authorization Server. Applications that supply their own consent page through the authorization endpoint configuration are not affected.

‍

Details

Module Info

• Product: Spring Authorization Server
• Affected packages: org.springframework.security:spring-security-oauth2-authorization-server
• Affected versions: >=1.4.0 <=1.4.11, >=1.5.0 <=1.5.8
• GitHub repository: https://github.com/spring-projects/spring-authorization-server
• Published packages: https://central.sonatype.com/artifact/org.springframework.security/spring-security-oauth2-authorization-server
• Package manager: Maven
• Fixed in:
• NES for Spring Authorization Server: nes-v1.5.10, nes-v1.4.13, nes-v1.3.12, and nes-v1.2.15

Vulnerability Info

This High-severity vulnerability is found in the org.springframework.security:spring-security-oauth2-authorization-server package in the default consent page of Spring Authorization Server.

When an authorization request or a device verification request requires user consent and the application has not configured a custom consent page, the authorization server renders its built-in consent screen. That screen is assembled by concatenating strings into a StringBuilder, and every request-influenced value that reaches it is written directly into the markup with no HTML entity encoding: the client_id, the state parameter, the request URI, the user_code parameter, the authenticated principal name, and each requested scope.

Because an unauthenticated attacker controls the contents of the authorization request, they can craft a link whose parameters carry markup. When a victim who is authenticated to the authorization server follows that link, the payload is echoed into the consent HTML and executed by the victim's browser in the authorization server's origin, where it can read session cookies, rewrite the consent form, or silently submit consent for scopes the user never reviewed. Scope values persisted with a registered client are rendered by the same code path, so a payload stored server-side is replayed to every user who reaches the consent screen for that client.

private static String generateConsentPage(HttpServletRequest request, String clientId, Authentication principal,
        Set<String> requestedScopes, Set<String> authorizedScopes, String state,
        Map<String, String> additionalParameters) {

    // ...

    String userCode = additionalParameters.get(OAuth2ParameterNames.USER_CODE);

    StringBuilder builder = new StringBuilder();

    // ...

    builder.append("            <p><span class=\"font-weight-bold text-primary\">" + clientId + "</span> wants to access your account <span class=\"font-weight-bold\">" + principal.getName() + "</span></p>");

    if (userCode != null) {
        builder.append("            <p class=\"alert alert-warning\">You have provided the code <span class=\"font-weight-bold\">" + userCode + "</span>. Verify that this code matches what is shown on your device.</p>");
    }

    builder.append("            <form name=\"consent_form\" method=\"post\" action=\"" + request.getRequestURI() + "\">");
    builder.append("                <input type=\"hidden\" name=\"client_id\" value=\"" + clientId + "\">");
    builder.append("                <input type=\"hidden\" name=\"state\" value=\"" + state + "\">");
    if (userCode != null) {
        builder.append("                <input type=\"hidden\" name=\"user_code\" value=\"" + userCode + "\">");
    }

    for (String scope : scopesToAuthorize) {
        builder.append("                <div class=\"form-group form-check py-1\">");
        builder.append("                    <input class=\"form-check-input\" type=\"checkbox\" name=\"scope\" value=\"" + scope + "\" id=\"" + scope + "\">");
        builder.append("                    <label class=\"form-check-label\" for=\"" + scope + "\">" + scope + "</label>");
        builder.append("                </div>");
    }

    // ...
}

None of the interpolated values pass through an HTML escaping helper before reaching the response body, and the response is served as text/html, so the injected markup is parsed as part of the trusted page rather than as text.

‍

Mitigation

No open-source release of the standalone Spring Authorization Server project carries the fix on any line. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Migrate to the authorization server support in Spring Security OSS 7.x.
• Configure a custom consent page through the authorization endpoint configuration, so that the built-in renderer is never used.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Yu Bao from PayPal Cybersecurity Team (finder)