CVE-2026-49283

## 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.

## 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.