CVE-2026-41003 - Spring Security generated form XSS

Affected Spring Security releases could emit unencoded values from RelyingPartyRegistration into HTML forms generated by framework filters. If an attacker can influence those registration values, they may execute script in the browser of a user handling that authentication flow.

This is only relevant where the repository both uses the affected generated forms and lets less-trusted input shape RelyingPartyRegistration data. Static internal-only metadata with strong control boundaries is lower risk, but still worth patching.

When to use it

Use this recipe when a Spring Security application uses generated SAML/OIDC authentication forms and RelyingPartyRegistration metadata can be influenced by tenant, admin, connector, or external identity-provider input. It is built for source-code remediation, generated-HTML encoding review, auth-flow XSS testing, and evidence that registration values cannot become scriptable form markup.

Inputs

  • Spring Security version, dependency tree, SAML/OIDC configuration, RelyingPartyRegistration source, generated form usage, and identity-provider onboarding model.
  • Source/config paths that build relying-party metadata, import IdP config, render framework-generated forms, or expose tenant/admin registration flows.
  • Regression fixtures for attacker-influenced registration values, benign IdP metadata, generated forms, escaped output, and rejected unsafe values.
  • Boundary evidence: who can modify registration data, affected auth flows, cookies/session posture, logs, and rollout owner.

Affected versions

  • Vulnerable package: Spring Security 5.7.0-5.7.23, 5.8.0-5.8.25, 6.3.0-6.3.16, 6.4.0-6.4.16, 6.5.0-6.5.10, 7.0.0-7.0.5
  • Fixed versions: 5.7.24, 5.8.26, 6.3.17, 6.4.17, 6.5.11, 7.0.6
  • Affected surface: framework-generated HTML forms backed by attacker-influenced RelyingPartyRegistration values

Indicator-of-exposure

  • The repository uses Spring Security login, logout, SAML, or OIDC flows that render generated forms.
  • RelyingPartyRegistration data is constructed from tenant input, remote metadata, admin-configurable values, or partner-provided data.
  • There are multi-tenant or dynamic identity provider onboarding flows.
  • Output encoding is delegated to the framework-generated form.

Quick checks:

rg -n "RelyingPartyRegistration|saml2Login|Saml2|oauth2Login|DefaultLoginPageGeneratingFilter|Saml2WebSsoAuthenticationRequestFilter|registrationRepository" .
mvn -q dependency:tree | rg "spring-security"
gradle dependencies --configuration runtimeClasspath | rg "spring-security"

Windows:

rg -n "RelyingPartyRegistration|saml2Login|Saml2|oauth2Login|DefaultLoginPageGeneratingFilter|Saml2WebSsoAuthenticationRequestFilter|registrationRepository" .
mvn -q dependency:tree | rg "spring-security"
gradle dependencies --configuration runtimeClasspath | rg "spring-security"

Remediation strategy

  • Upgrade Spring Security to the fixed release for the maintained branch.
  • Review all dynamic registration and identity-provider metadata flows.
  • Add regression tests that assert generated HTML escapes registration-derived values and that malicious characters are inert.
  • If upgrade is blocked, reduce exposure by rejecting untrusted HTML-capable values before they are stored in RelyingPartyRegistration.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-41003, where Spring Security may render
attacker-influenced `RelyingPartyRegistration` values into generated HTML
without proper encoding. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Spring Security, hardens
  registration data handling, adds safe regression checks, and documents
  operator actions, or
- TRIAGE.md if this repository does not control an affected generated-form
  authentication path.

## Rules

- Scope only CVE-2026-41003 and directly related generated-form rendering and
  registration-input handling.
- Treat identity metadata, tenant config, certificates, domains, and user data
  as sensitive.
- Do not test with live customer tenants or injected production identity
  metadata.
- Do not strip legitimate form functionality just to avoid rendering.
- Do not auto-merge.

## Steps

1. Inventory Spring Security dependencies, login flows, SAML/OIDC config,
   generated-form filters, lockfiles, images, and SBOMs.
2. Determine which targets resolve vulnerable Spring Security versions.
3. Trace all places where `RelyingPartyRegistration` values originate and
   whether less-trusted actors can influence them.
4. If no affected generated-form path is controlled here, stop with `TRIAGE.md`
   listing checked files and the runtime owner if external.
5. Upgrade all controlled Spring Security references to the fixed release.
6. Ensure registration-derived values rendered into generated forms are safely
   encoded or constrained to trusted values only.
7. Add safe regression tests asserting malicious registration values render as
   inert text, not executable HTML or script.
8. Add a PR body section named `CVE-2026-41003 operator actions` that states:
   - versions before and after;
   - which generated authentication forms were in scope;
   - whether dynamic or tenant-driven registration data exists;
   - any containment applied;
   - which validation commands passed.
9. Run available validation: dependency resolution, MVC/security tests,
   template rendering tests, container build, and security scans.
10. Use PR title:
    `fix(sec): remediate CVE-2026-41003 in Spring Security`.

## Stop conditions

- No affected generated-form path is controlled here.
- Verification would require injecting active payloads into live tenant or
  identity-provider flows.
- Upgrade requires a broader framework migration outside scope.
- Validation fails for unrelated pre-existing reasons; document them instead of
  broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Spring Security, verifies generated form encoding, adds auth-flow XSS tests, and documents IdP metadata validation.
  • Or a TRIAGE.md file that lists inspected files/config, owner, observed version, registration-data boundary, generated forms, required fix, and residual risk.
  • The output must include exact validation commands and must not include live XSS payloads against production, expose SSO metadata secrets, or print user session data.

Verification - what the reviewer looks for

  • No controlled build resolves a vulnerable Spring Security line.
  • Generated forms escape or reject attacker-influenced registration values.
  • Tests cover malicious characters in dynamic registration fields.

Watch for

  • Patching dependency versions while an internal library still pins an older Spring Security branch.
  • Assuming only SAML is in scope when another generated form reuses the same value path.

References