CVE-2026-18108

The vulnerability in this SAML library inverts the fundamental trust decision: it treats 'no signature element exists' as equivalent to 'verified.' The code literally says `return $xml unless $xpath->exists('dsig:Signature')` — if the signature element is missing, the assertion is treated as authenticated and returned to the caller. This is backwards. The absence of a signature is not a trust signal — it's a missing prerequisite. The critical confusion is conflating decryption with authentication. The service provider holds the private key, so it can always decrypt assertions encrypted to its certificate. That proves only that the SP's key was used — something already known. It says nothing about who created the assertion or whether a trusted identity provider issued it. The library uses decryption success as a stand-in for verification, which it is not. Do not frame this as affecting a 'narrow' or 'corner case' deployment. The vulnerability requires two conditions: the SP must have a decryption key configured AND the IdP must encrypt assertions (not just sign them). But the SP's encryption certificate is published in SAML metadata — there is no reconnaissance required. An attacker reads the public metadata, encrypts a forged assertion to the SP's certificate, and POSTs it to the login endpoint. The attack surface is a public endpoint that accepts arbitrary assertions, not a restricted channel. Encrypted assertions are used precisely in cross-organizational federations — the higher-sensitivity scenario where assertions pass through intermediaries or untrusted infrastructure. This is not a corner case; it's the deployment where explicit authentication matters most. Check your deployment: if you configure a decryption key in this library, verify that your IdP partners sign their assertions and that your library configuration requires signature validation. The fix in the update is straightforward — the code now fails closed when no signature exists. But the deeper fix is recognizing that decryption capability and signature verification must not be independent configuration knobs. If you accept encrypted assertions, cryptographic proof of issuer identity is mandatory, not optional.

Reviewed through automated stages and approved by a human before publication.