Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft XML with two or more dsig:Signature elements
-
DeliverySet Reference URIs to IDs absent from the document
-
ExploitSubmit forged XML to application calling verify()
-
Executionverify() skips all signatures before any cryptographic check
-
Persistverify() returns true unconditionally
-
ImpactApplication accepts forged document as cryptographically valid
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Exploitation requires the target application to pass attacker-controlled XML to XML::Sig's verify() function on a version between 0.29 and 0.71 inclusive. Two distinct triggering paths exist: (1) the crafted XML contains two or more dsig:Signature elements where at least one SignedInfo/Reference/@URI resolves to no element in the document - this triggers the numsigs-greater-than-1 skip regardless of id_attr setting; (2) the application sets the id_attr option and the Reference does not match the requested ID. Providing a cert or cert_text trust anchor does not prevent exploitation because no key check is reached. Exploitation is bounded by: the application must actually invoke verify() on untrusted input; the version range is strictly 0.29-0.71 (the vulnerable XPath-based path was introduced in 0.29); and versions 0.28 and earlier are immune due to a different verify implementation. |
| Impact | The CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) accurately represents the attack profile: no authentication required, no user interaction, low complexity, and full integrity bypass. This is not a case of inflated CVSS - the bypass is straightforward to trigger, requiring only two Signature elements with Reference URIs pointing to nonexistent element IDs, as demonstrated by the test case in the fix commit. EPSS data was not provided in the available intelligence, so probabilistic exploitation likelihood cannot be quantified. This CVE is not currently listed in the CISA KEV catalog, and no public standalone exploit has been identified beyond the commit-embedded test. The practical impact is severe for any application using XML::Sig for authentication, authorization, or data integrity decisions: an attacker can forge arbitrary signed XML that is accepted as valid. Applications that supply a cert or cert_text trust anchor are equally affected because no key check reaches execution under the vulnerable control flow, making the trust anchor a false sense of security. |
| Exploit ScenarioDerived | An attacker submits a crafted XML document to a SAML assertion processor or other XML signature-verifying application built on XML::Sig 0.29-0.71. The document contains two dsig:Signature elements whose SignedInfo/Reference/@URI values reference an element ID that does not exist anywhere in the document. The verify() function iterates over both signatures, silently skips each before performing any digest or key check via the numsigs-greater-than-1 path, and returns true. The attacker's document - with arbitrary tampered content - is accepted as cryptographically valid, potentially granting elevated privileges or bypassing access controls. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 03, 2026
Signature verification bypass in XML::Sig (Perl) versions 0.29 through 0.71 allows remote unauthenticated attackers to submit arbitrary XML documents that are accepted as cryptographically valid without any digest or key check ever running. The verify() function unconditionally returns true after looping over all dsig:Signature elements, even when every iteration exited early via a skip path before cryptographic validation. No public exploit has been identified beyond the proof-of-concept test case embedded in the fix commit, and this vulnerability is not currently listed in the CISA KEV catalog.
RemediationAI
Upgrade XML::Sig to version 0.72 or later using 'cpanm XML::Sig' or the equivalent package manager command; the release is confirmed at https://metacpan.org/release/TIMLEGGE/XML-Sig-0.72/changes and the source patch at https://github.com/perl-net-saml2/perl-XML-Sig/commit/ef22cfed1ac0f29b316d17eb79cf6480e03ae16a.patch. If an immediate upgrade is not feasible, a targeted compensating control is to pre-validate XML input before passing it to verify(): reject any document containing more than one dsig:Signature element, and reject any document where a Reference URI attribute does not resolve to an element in the document - this eliminates both documented skip paths without requiring library changes, though it adds application-layer parsing overhead. A second workaround is to restrict the application to processing only internally-generated XML, eliminating the attacker's ability to supply crafted input; this trade-off limits functionality in use cases involving third-party signed documents. There is no configuration-level mitigation within the library itself prior to v0.72.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
XML::Sig is a Perl CPAN module (CPE: cpe:2.3:a:timlegge:xml::sig) implementing W3C XML Digital Signature generation and verification, commonly used in SAML and XML security workflows. The root cause is CWE-347 (Improper Verification of Cryptographic Signature). In lib/XML/Sig.pm, the verify() subroutine counts dsig:Signature elements into $numsigs and iterates over them, but two distinct code paths reach a 'next' statement before any digest validation or key material check runs: first, when a SignedInfo/Reference/@URI resolves to no DOM element and $numsigs is greater than 1; second, when the id_attr option is configured and a reference does not match the requested ID. Because the loop tracks only signatures present rather than signatures verified, and the function terminates with an unconditional 'return 1', all signatures following skip paths produce a true return. The v0.72 fix introduces a $verified counter incremented only after a full cryptographic check, returning 0 if $verified remains zero post-loop. Versions 0.28 and earlier used a separate XML::XPath-based verify implementation with different control flow and are not vulnerable to this issue.
Know when Xml gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Network-reachable with no prerequisites beyond submitting XML; full integrity bypass with no confidentiality or availability impact, consistent with NVD scoring.
Primary rating from Vendor (CPANSec).
CVSS VectorVendor: CPANSec
Lifecycle Timeline
3DescriptionCVE.org
XML::Sig versions from 0.29 before 0.72 for Perl allow signature verification bypass because verify returns true when every signature was skipped before any cryptographic check.
verify in lib/XML/Sig.pm counts the //dsig:Signature elements into $numsigs and iterates over them, but two paths reach next before any digest or key check runs: a SignedInfo/Reference/@URI that resolves to no element while $numsigs is greater than 1, and, when id_attr is set, a reference that does not match the requested ID. The loop records nothing about what it checked, so when every signature takes one of those paths control reaches the unconditional return 1 that ends verify. Two Signature elements whose Reference URI names an ID that no element carries is enough, as is one such element combined with id_attr.
Any caller that passes untrusted XML to verify can receive a true return for a document in which no digest and no signature value was checked; a cert or cert_text trust anchor does not change this, because no key check runs. Versions up to 0.28 use an XML::XPath based verify that has no such skip and are not affected.
Executive ViewAI
XML::Sig (Perl) versions 0.29-0.71 contain a signature verification bypass allowing unauthenticated attackers to forge XML signatures and bypass authentication controls. Publicly available exploit code exists. Organizations using this library for SAML, digital signatures, or document validation face direct risk of accepting forged documents as legitimate.
Patch available per vendor advisory.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Malformed UTF-16 decoding in libexpat through 2.8.4 lets remote attackers hide XML markup from the parser: a lone high s
XML-Sig versions 0.27 through 0.67 for Perl incorrectly validates XML files if signatures are omitted. Rated critical se
Signature-verification bypass in the Perl XML::Sig module before 0.71 allows remote attackers to forge which document no
Out-of-bounds read in the XML::Bare Perl XML parser (all releases through 0.53) lets a remote attacker crash the parsing
Signature verification bypass in the Perl XML::Sig module before 0.71 allows XML Signature Wrapping (XSW) via duplicate
Out-of-bounds heap read in XML::LibXML for Perl (all versions through 2.0210) allows remote attackers to trigger denial-
Denial of service in the Perl XML::Bare module (versions through 0.53) allows remote attackers to force an infinite loop
EUVD-2026-52325
GHSA-r3hj-rg3j-262c
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB