CVE-2026-41003: Spring Security SAML XSS via RelyingPartyRegistration

On June 9, 2026, the Spring team disclosed CVE-2026-41003, a HIGH-severity (CVSS 3.1 score 7.6, vector AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N) cross-site scripting flaw (CWE-79) in Spring Security's SAML 2.0 support. An attacker who can influence values in a RelyingPartyRegistration can cause unencoded markup to be written into the HTML forms that Spring Security's SAML filters auto-generate, allowing arbitrary JavaScript to run in a victim's browser. It affects Spring Security 5.7.0 through 5.7.23, 5.8.0 through 5.8.25, 6.3.0 through 6.3.16, 6.4.0 through 6.4.16, 6.5.0 through 6.5.10, and 7.0.0 through 7.0.5. 

Running Spring Security on an unsupported version? See NES for Spring.

‍

What is CVE-2026-41003?

CVE-2026-41003 is a cross-site scripting vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation) in the SAML 2.0 service-provider components of Spring Security.

When an application acts as a SAML 2.0 relying party (service provider), Spring Security generates HTML forms to drive the SAML protocol exchange, for example the auto-submitting POST form used to relay an AuthnRequest or a logout request to the asserting party. Several of the values placed into those forms are drawn from the RelyingPartyRegistration that describes the relying party and its identity-provider endpoints: destination URLs, entity IDs, and similar fields.

The vulnerability is that one or more of these values are written into the generated HTML without proper contextual output encoding. If an attacker can influence the content of a RelyingPartyRegistration, they can inject markup, such as a <script> tag or an event-handler attribute, that the browser then parses and executes when the generated form is rendered. Spring's own advisory phrases this as the ability to "run arbitrary code on HTML forms generated by Spring Security filters." The "code" here is browser-side script, which is why the issue is classified as XSS (CWE-79) rather than server-side remote code execution.

‍

Severity and exploit conditions

Rated 7.6 HIGH under CVSS 3.1.

The PR:L rating is the most important nuance for triage. This is not a "send an anonymous request and pop a shell" vulnerability. Exploitation depends on an attacker being able to influence the values that populate a RelyingPartyRegistration. The realistic exposure is highest where relying-party metadata or endpoint values are sourced from data that is not fully trusted or fully validated: multi-tenant SAML setups where tenants supply their own identity-provider details, registrations built from externally fetched IdP metadata, or administrative interfaces where lower-privileged operators can edit registration fields. The UI:R and S:C combination reflects a classic stored or reflected XSS chain: the payload lands in a registration, a victim is steered to the generated form, and the script runs in their session.

‍

What an attacker can do

Concretely, an attacker who lands script execution in the relying-party form context can:

• Steal session material: read cookies not marked HttpOnly, and read tokens held in localStorage, sessionStorage, or page memory for the affected origin.
• Hijack the SAML exchange: alter the destination of the auto-submitting form or capture the SAMLRequest / SAMLResponse and relay-state values as they pass through the browser.
• Drive authenticated actions: issue fetch or XMLHttpRequest calls to same-origin endpoints using the victim's existing session, performing actions as the victim.
• Serve phishing content: rewrite the rendered page to capture credentials or push the user to an attacker-controlled identity provider.

Because the SAML form sits directly in the authentication path, a successful payload executes precisely at the moment a user is establishing or relaying a federated session, which is a high-value window for credential and token theft.

‍

Who is affected?

The vulnerability affects applications using Spring Security's SAML 2.0 service-provider support across the version ranges below. Spring shipped OSS fixes only for the 6.5.x and 7.0.x lines; the 5.7.x, 5.8.x, 6.3.x, and 6.4.x branches have reached OSS end-of-life.

This is the crux of the EOL gap. Two of the six affected branches (6.5.x, 7.0.x) get a free OSS patch. The other four, plus everything older, will not be receiving an OSS fix.

‍

Mitigation guidance

‍

Related CVEs

This is the latest in a sustained run of Spring Security and Spring ecosystem disclosures. If you are remediating CVE-2026-41003, these recent siblings are worth checking in the same pass:

• CVE-2026-22732: Spring Security silently drops HTTP security headers under certain configurations.
• CVE-2026-22752: Critical XSS, SSRF, and privilege escalation issues in Spring Authorization Server.
• CVE-2025-41254: Spring WebSocket CSRF bypass.
• CVE-2024-38821: Authorization bypass in Spring WebFlux applications.

‍

Taking action

If you run Spring Security 6.5 or 7.0, the fix is a version bump and you should apply it now. If you run 5.7, 5.8, 6.3, or 6.4, there is no OSS fix available.

For organizations standardized on EOL Spring Security lines, especially in large SAML-federated enterprise applications where a major-version upgrade is a multi-quarter project, NES for Spring provides a secure, drop-in replacement with this CVE remediated, so you stay protected without an emergency migration. To scope coverage for your specific version line, reach out via the HeroDevs contact page or review options on the pricing page.