Post

CVE-2026-49283: HTTP-Artifact TLS validator confusion in SimpleSAMLphp SAML2

Posted Updated
By Kamil Sawicki
3 min read
CVE-2026-49283: HTTP-Artifact TLS validator confusion in SimpleSAMLphp SAML2

I reported an HTTP-Artifact validation issue in SimpleSAMLphp’s SAML2 libraries that was published as CVE-2026-49283 / GHSA-6929-8p9f-26jx.

The bug was a validator confusion issue in the HTTP-Artifact receive path. In a multi-IdP deployment, an ArtifactResponse obtained from one IdP could be used as validation proof for an embedded SAML Response claiming to be issued by another IdP.

Advisory

  • CVE: CVE-2026-49283
  • GitHub Advisory: GHSA-6929-8p9f-26jx
  • Packages:
    • simplesamlphp/saml2
    • simplesamlphp/saml2-legacy
  • Affected simplesamlphp/saml2 versions:
    • < 6.2.1
    • < 5.0.6
    • < 4.20.2
  • Patched simplesamlphp/saml2 versions:
    • 6.2.1
    • 5.0.6
    • 4.20.2
  • Affected simplesamlphp/saml2-legacy versions:
    • < 4.20.2
  • Patched simplesamlphp/saml2-legacy version:
    • 4.20.2
  • Severity: High 8.7/10
  • CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N
  • CWE: CWE-295: Improper Certificate Validation

Root Cause

SAML HTTP-Artifact is a two-step flow. The browser sends a small artifact to the SP, and the SP resolves it over a back-channel SOAP request to the IdP’s Artifact Resolution Service. The SOAP response contains an ArtifactResponse, which can embed the actual SAML Response.

The vulnerable chain was:

  1. The SOAP ArtifactResponse received a TLS-based validator.
  2. The embedded SAML Response received a validator that delegated validation to the outer ArtifactResponse.
  3. The SP later interpreted the embedded Response issuer independently and selected IdP metadata based on that embedded issuer.
  4. The TLS validator returned normally on public-key mismatch instead of throwing an error.
  5. The message validation layer treated a validator that returned without throwing as success.

The result was a broken binding between:

  • the IdP that served the artifact over SOAP/TLS; and
  • the IdP named by the embedded SAML Response.

In a multi-IdP environment, that distinction matters. A lower-trust or compromised IdP should not be able to mint authentication material that is interpreted as coming from a different, higher-trust IdP.

Impact

The public advisory describes the issue as an authentication bypass and IdP impersonation problem for HTTP-Artifact deployments.

The most relevant affected deployment shape is:

  • the SP accepts SAML responses through HTTP-Artifact;
  • the SP trusts multiple IdPs or federation participants;
  • at least one lower-trust, malicious, or compromised IdP can issue an ArtifactResponse;
  • the application maps SAML attributes, NameID, or session data into an authenticated local session;
  • authorization or assurance decisions depend on which IdP issued the identity.

Under those conditions, the attacker can cause the SP to accept an embedded unsigned Response as if it came from another trusted IdP. The attacker-controlled assertion data can then be used to create a local authenticated session.

Why This Was Easy To Miss

The bug was not a classic signature forgery. It was a trust-binding problem between nested protocol messages.

Individually, the pieces can look reasonable:

  • HTTP-Artifact has an outer SOAP response and an embedded SAML response.
  • The outer response can be protected by TLS.
  • The embedded response is validated later against IdP metadata.
  • Validators are callback-based.

The security failure came from the interaction between those pieces. A validator attached because of one security context was reused in another security context, and the TLS mismatch path did not fail closed.

That is the key lesson: validator callbacks should be explicit about what exactly they authenticate. A validator proving “this ArtifactResponse came over TLS from IdP A” must not be reusable as proof that “this embedded Response was issued by IdP B”.

Fix Direction

The fix needs to make validation fail closed when the TLS key does not match and needs to preserve issuer binding between the artifact issuer, the ArtifactResponse, and the embedded SAML Response.

Defensive principles:

  • TLS-derived validators must throw on key mismatch.
  • Delegated validation must not cross issuer boundaries silently.
  • Embedded messages should be validated against the issuer and metadata that actually correspond to the artifact resolution context.
  • Tests should cover multi-IdP cases, not only single-IdP happy paths.

References

security, cve
simplesamlphp saml http-artifact authentication-bypass
This post is licensed under CC BY 4.0 by the author.