CVE-2026-47877

Overview

Spring Security is the authentication and access-control framework for the Spring application stack, providing servlet and reactive filter chains, OAuth2 and OpenID Connect support, method security, and cryptography helpers. Since Spring Security 7.0.0 it also contains the OAuth2 authorization server, previously released separately as Spring Authorization Server, which issues tokens and renders the end-user consent screen that an authorization request can require.

A Cross-Site Scripting (XSS) vulnerability (CVE-2026-47877) has been identified in the default consent page of the Spring Security OAuth2 authorization server, which allows attackers to execute arbitrary script in the browser of an end user who is asked to approve an authorization request. Because the injected value is supplied in the authorization request and rendered back on a page the user is expected to trust and act on, the flaw can also be used to alter what the consent screen appears to ask for, a form of Content Spoofing.

Per OWASP: XSS attacks are serious and can lead to account impersonation, observing user behavior, loading external content, stealing sensitive data, and more.

This issue affects versions >=7.0.0 <=7.0.6 and 7.1.0 of Spring Security.

Details

Module Info

• Product: Spring Security
• Affected packages: org.springframework.security:spring-security-oauth2-authorization-server
• Affected versions: >=7.0.0 <=7.0.6, 7.1.0
• GitHub repository: https://github.com/spring-projects/spring-security
• Published packages: https://central.sonatype.com/artifact/org.springframework.security/spring-security-oauth2-authorization-server
• Package manager: Maven

Vulnerability Info

This Critical-severity vulnerability is found in the org.springframework.security:spring-security-oauth2-authorization-server package in versions >=7.0.0 <=7.0.6 and 7.1.0 of Spring Security.

The authorization endpoint renders the built-in consent screen through DefaultConsentPage, whose generateConsentPage method assembles the page as a single HTML string. Values taken from the authorization request and from the current session are appended directly into that string with no HTML entity encoding: the client_id parameter, the state parameter, the authenticated principal name, the request URI, the user_code additional parameter, and every requested scope.

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>");
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 + "\">");
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>");

Several of these values sit inside double-quoted HTML attributes, so a value carrying a double quote closes the attribute early and lets the remainder of the value be parsed as markup, while principal.getName() and each scope label are written into element text where a tag is interpreted directly. An attacker who can induce a victim to follow a crafted authorization request, or who can register or influence a client whose identifier or requested scopes are attacker-chosen, therefore controls markup on the consent page. The value is stored server side as part of the pending authorization and rendered when the user is prompted, so the script runs in the context of the authorization server origin, the same origin that holds the user's authenticated session, which is why the scope metric for this issue is rated as changed.

Applications that replace the built-in page with a custom consent page, configured through OAuth2AuthorizationServerConfigurer.authorizationEndpoint(c -> c.consentPage(...)), do not render DefaultConsentPage and are not affected.

This vulnerability was introduced in 2025 with Spring Security 7.0.0.

Mitigation

Only recent versions of Spring Security receive community support. 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:

• Upgrade to a currently supported version of Spring Security.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Yu Bao from PayPal Cybersecurity Team (finder)