Packagist · simplesamlphp/simplesamlphp
SimpleSAMLphp SP accepts a response from an unexpected IdP when unsigned `Response/InResponseTo` is combined with a signed assertion lacking `SubjectConfirmationData/InResponseTo`
SimpleSAMLphp's SAML SP ACS path does not enforce the IdP selected for an SP-initiated login. If a saved SP state contains ExpectedIssuer = IdP A, but the ACS receives a valid response from IdP B, the code logs a warning and continues processing instead of rejecting the response.
That behavior becomes security-relevant when combined with the response-processing rule that accepts an unsigned samlp:Response/@InResponseTo outside the signed assertion whenever the signed assertion's SubjectConfirmationData does not carry its own InResponseTo. A response issued by one trusted IdP can therefore be bound to SP state created for another IdP.
In a multi-IdP deployment, a lower-trust IdP can satisfy SP state created for a different expected IdP. This can bypass an SP flow that intentionally routes the user to a specific IdP, including deployments that set enable_unsolicited to false to prevent IdP-initiated logins.
The impact is highest when the SP trusts multiple IdPs with different assurance levels, tenant boundaries, or attribute namespaces, and application authorization depends on the selected/expected IdP. In those deployments this is an authentication/authorization bypass candidate. Impact strongly depends on whether an attacker can obtain a signed IdP-initiated assertion from a lower-trust trusted IdP and whether the downstream application maps identifiers globally.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.