Description

The SimpleSAMLphp SAML2 library is a PHP library for SAML2 related functionality. Prior to versions 4.19.3, 4.20.2, 5.0.6, and 6.2.1, the HTTPArtifact::receive() flow can treat an unsigned embedded SAML Response as cryptographically valid for the wrong identity provider. SOAPClient::addSSLValidator() attaches a TLS-based validator to the outer SOAP ArtifactResponse, while the embedded Response receives a validator that delegates to the outer message and is later checked against metadata selected from the embedded response issuer rather than necessarily the artifact issuer. SOAPClient::validateSSL() returns normally when the TLS public key does not match the key being validated, and SAML2\Message::validate() treats a validator call that does not throw as successful. In a multi-IdP federation, a malicious or lower-trust IdP can therefore provide an ArtifactResponse containing an unsigned Response that claims a higher-trust victim IdP as issuer and authenticate as arbitrary users with attacker-chosen assertion attributes, NameID, and session data. This issue is fixed in versions 4.19.3, 4.20.2, 5.0.6, and 6.2.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.7",
  "pubDate": "2026-08-19T15:17:07.027Z",
  "pubdate": "2026-08-19T15:17:07.027Z",
  "executiveSummary": "An improper validation vulnerability exists in the SimpleSAMLphp SAML2 library within the HTTPArtifact::receive() flow. Specifically, the vulnerability arises because the library can treat an unsigned embedded SAML Response as cryptographically valid for the wrong identity provider.\nThe impact of this security flaw is severe, allowing a malicious or lower-trust Identity Provider (IdP) within a multi-IdP federation to authenticate as arbitrary users with attacker-chosen assertion attributes, NameID, and session data, effectively impersonating a higher-trust victim IdP.\nAffected systems include versions of the SimpleSAMLphp SAML2 library prior to 4.19.3, 4.20.2, 5.0.6, and 6.2.1.\nThe risk implications involve complete compromise of authentication and session integrity in federated environments utilizing artifact resolution.\nAttacker capabilities require control over or compromise of a malicious/lower-trust IdP participating in the same multi-IdP federation, enabling them to craft and deliver spoofed ArtifactResponses containing unsigned embedded responses.",
  "technicalDetails": "The vulnerability resides in the HTTPArtifact::receive() flow of the SimpleSAMLphp SAML2 library, specifically involving SOAPClient::addSSLValidator(), SOAPClient::validateSSL(), and SAML2\\Message::validate().\nThe root cause stems from how TLS-based validators are attached and subsequently verified. SOAPClient::addSSLValidator() attaches a TLS-based validator to the outer SOAP ArtifactResponse. Meanwhile, the embedded Response receives a validator that delegates validation to the outer message.\nDuring message processing, this embedded validator is checked against metadata selected from the embedded response issuer rather than the actual artifact issuer.\nCompounding this logic flaw, SOAPClient::validateSSL() returns normally when the TLS public key does not match the key being validated, and SAML2\\Message::validate() treats any validator call that does not throw an exception as a successful validation.\nThe step-by-step attack flow in a multi-IdP federation proceeds as follows: 1) A malicious or lower-trust IdP initiates or participates in an artifact resolution flow. 2) The malicious IdP provides an ArtifactResponse containing an unsigned Response. 3) The embedded Response falsely claims a higher-trust victim IdP as its issuer. 4) Due to the improper validator delegation and metadata selection logic, the library evaluates the embedded response against the victim IdP's metadata instead of the communicating artifact issuer. 5) Because SOAPClient::validateSSL() fails silently without throwing an exception on key mismatches, SAML2\\Message::validate() interprets the check as successful. 6) The service provider accepts the unsigned embedded SAML Response as cryptographically valid.\nPost-exploitation impact enables the attacker to successfully authenticate as arbitrary users, injecting arbitrary assertion attributes, NameID values, and session data attributed to the victim IdP."
}