CVE-2026-18092 is being treated as a signature verification flaw, but that framing misses the actual problem. The library correctly verifies that the element referenced by the signature's Reference URI has not been tampered with. The vulnerability is that identity fields are then extracted using document-wide XPath queries — //saml:Assertion/saml:Subject/saml:NameID — that return the first matching element in document order, regardless of which element the signature actually covers. These are not the same thing. An attacker who holds one legitimate IdP-signed assertion can inject an unsigned assertion containing a target user's NameID and attributes before the signed one in the document tree; the signature verifies, but the XPath returns the attacker's fabricated data.
This is a mismatch between the scope of cryptographic trust and the scope of data consumption. The cacert configuration creates a misleading security signal — it confirms a signature is present on something in the document, but it does not confirm that the identity data being consumed comes from the signed subtree.
The EPSS score of 0.00196 assumes an external attacker who has somehow obtained a valid assertion, which understates the realistic threat surface. In IdP-initiated flows, federation chains, and multi-SP SAML topologies, the party holding a valid assertion is often a legitimate participant in the trust architecture — a service provider receiving assertions from an IdP already has exactly what they need to forge an unsigned sibling assertion for a different user. The blast radius is broader than the EPSS score suggests.
The fix is not patching signature verification. The library must either scope XPath queries to the signed subtree (using descendant-or-self::node()[ancestor::E] where E is the signed element), or explicitly expose which assertion element the signature covers so callers can correlate identity data extraction with the verified element. The current behavior was never an explicit API contract — it was an undocumented assumption that cacert secured the entire data consumption operation. Maintainers should treat this as a security-critical correction, not a breaking-change debate. The cost of a slightly disruptive migration is orders of magnitude lower than the cost of maintaining a CVE that exists because the API design made the vulnerable pattern the path of least resistance.
Defenders should audit any code path that calls new_from_xml or equivalent identity extraction methods after signature verification — verify whether the identity data actually comes from the signed element, not from document order.