Summary SimpleSAMLphp's HTTP-Artifact receive path can treat an unsigned embedded SAML "Response" as cryptographically valid for the wrong IdP. In the "HTTPArtifact::receive()" flow, the SOAP "ArtifactResponse" receives a TLS-based validator from "SOAPClient::addSSLValidator()". The embedded SAML "Response" then receives a validator that delegates signature validation to that outer "ArtifactResponse". Later, the SP validates the embedded "Response" against metadata selected from the embedded response issuer, not necessarily the artifact issuer. The critical issue is that "SOAPClient::validateSSL()" returns normally when the TLS public key does not match the key currently being validated. "SAML2\Message::validate()" treats any validator call that does not throw an exception as successful. As a result, an "ArtifactResponse" obtained from one IdP can validate an unsigned embedded SAML "Response" that claims to be issued by a different IdP. In a multi-IdP/federation deployment where a malicious or lower-trust IdP can issue an HTTP-Artifact response to an SP, this can allow the attacker to authenticate to the SP as arbitrary users from a higher-trust victim IdP. Impact A malicious or lower-trust IdP in the same SP/federation trust set can authenticate to the SP as users from another IdP when HTTP-Artifact is used. The attacker can choose assertion attributes, "NameID", and session data in the forged unsigned assertion. This is an authentication bypass and identity-provider impersonation issue. In realistic federations, the security boundary between IdPs matters: a compromised or low-assurance IdP should not be able to mint identities for a high-assurance IdP.