Net::SAML2 CVE-2026-18092

The attacker must possess at least one valid SAML assertion issued and signed by the target Identity Provider - this may be an assertion for any account, including a low-privilege or self-registered one, but purely external parties who cannot obtain any IdP-signed assertion cannot exploit this flaw. The victim application must be running Net::SAML2 prior to version 0.86 and must pass untrusted SAML Response XML to new_from_xml. User interaction is required (CVSS UI:R): the victim must initiate a SAML authentication flow, creating the opportunity for the attacker to intercept or inject the crafted Response. Configuring a cacert CA trust anchor explicitly does NOT mitigate the vulnerability - the CA check passes against the attacker's own legitimately signed assertion, while the unsigned injected assertion is never separately verified. No non-default configuration is required on the SP side; the flaw exists in the default code path for SAML assertion processing.

The NVD CVSS 8.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H) contains two metrics that conflict with the described impact and warrant explicit scrutiny. C:N (no confidentiality impact) is inconsistent with a complete authentication bypass - an attacker who authenticates as an arbitrary user trivially accesses that user's confidential data; confidentiality impact should arguably be High. A:H (high availability impact) is unexplained by the vulnerability description, which describes no crash or denial-of-service path; this metric may reflect a secondary crash path under malformed XML or was applied conservatively, and should be verified with CPANSec. EPSS data was not provided in this record. Exploitation requires possession of at least one valid IdP-issued signed assertion, which elevates the practical barrier above fully unauthenticated network attacks and pushes real-world complexity higher than the AC:L metric implies. No KEV listing and no public exploit code have been identified at time of analysis. Despite these caveats, the technical impact is a complete authentication bypass with no configuration-based mitigation available other than upgrading - Perl applications using this library as a SAML SP should treat this as a high-priority patch, particularly those with high-value user accounts or federated enterprise SSO deployments.

An attacker creates a legitimate low-privilege account at the target IdP and obtains a valid CA-signed SAML assertion for their own identity. They construct a malicious SAML Response containing two assertions: first, an unsigned forged assertion embedding the victim's NameID and desired role attributes; second, their own legitimate CA-signed assertion. When the victim user initiates a SAML login flow, the attacker injects this crafted Response - for example, via session fixation, a malicious IdP-initiated link, or a MITM position - and the vulnerable new_from_xml extracts the victim's NameID from the first (unsigned) assertion while the signature on the attacker's own assertion passes CA verification, completing authentication as the victim. No public POC has been identified at time of analysis, though the XSW technique is well-documented in academic and conference literature.