Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N
Primary rating from Vendor (https://github.com/simplesamlphp/simplesamlphp) · only source for this CVE.
CVSS VectorVendor: https://github.com/simplesamlphp/simplesamlphp
Lifecycle Timeline
1DescriptionCVE.org
Summary
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.
Impact
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.
AnalysisAI
Authentication/authorization bypass in SimpleSAMLphp's SAML Service Provider ACS handler allows a lower-trust but trusted IdP to satisfy login state that was created for a different, expected IdP. Because the ACS only logs (rather than rejects) a mismatch between the saved ExpectedIssuer and the actual response issuer, and because the code accepts an unsigned samlp:Response/@InResponseTo when the signed assertion lacks its own InResponseTo, an attacker holding a signed IdP-initiated assertion from IdP B can bind it to SP state intended for IdP A. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; impact is conditional on multi-IdP deployments where authorization depends on the selected IdP.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-45284
GHSA-q8r6-xj3f-wrrm