This reflected XSS lives in an unusual place: the exception-handling path of a SAML authentication endpoint, not the primary token validation logic. That's the critical detail. Security reviews of SSO systems concentrate on the happy path—validating assertions, checking signatures, verifying issuer trust. The error path gets treated as boilerplate, written once during initial integration, and then forgotten. This vulnerability exists in that forgotten code.
The attack surface is explicitly unauthenticated. Anyone hitting the SAML endpoint triggers this error handler, regardless of whether they hold valid credentials. LightSaml library parameters are being echoed directly into HTTP responses—likely because the error handler was wired up to surface diagnostic information for debugging, with the assumption that error messages would be sanitized downstream or that error paths weren't user-facing. Neither assumption holds.
What makes this particularly potent is the session context. Users hitting this endpoint have just been redirected from an identity provider after attempting authentication—they're in a trust-transition state with high-credential density. Compromising a session here may have SSO implications beyond just the Admidio application, depending on how the IdP integration is configured. The CVSS 6.1 rating is misleading for this reason: it measures the single-request exploitability, not the cascade potential through the trust chain.
For detection: audit your SAML libraries' exception handling paths specifically. Check whether any exception-to-response translation layer treats library exceptions as trusted input. The pattern has appeared before in python-saml and ruby-saml ecosystems—LightSaml is the latest instance. For remediation: verify whether the patched version addresses the architectural behavior (exception parameter reflection) or just encodes this specific injection point. If it's the latter, similar vectors likely remain in other error paths using the same infrastructure. Assume your SAML error handlers are unmaintained until proven otherwise—assign explicit ownership and review them as rigorously as your authentication success path.