CVE-2024-32962: xml-crypto vulnerable to XML signature verification bypass due improper verification of signature/signature spoofing

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• Not in CISA KEV, but CISA’s SSVC assessment records a public proof-of-concept, so attack code exists.
• EPSS 0.8%, percentile 57: FIRST’s model estimates a 0.8% chance of exploitation activity in the next 30 days, higher than 57% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes xml-crypto (npm) >= 4.0.0, < 6.0.0, fixed in 6.0.0. Check your lockfile, including transitive dependencies.

What it is

xml-crypto is an xml digital signature and encryption library for Node.js. In affected versions the default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of the w3 xmldsig-core-20080610 spec. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a element, and pass xml-crypto default validation checks. As a result xml-crypto trusts by default any certificate provided via digitally signed XML document's . xml-crypto prefers to use any certificate provided via digitally signed XML document's even if library was configured to use specific certificate (publicCert) for signature verification purposes. An attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to element. This vulnerability is combination of changes introduced to 4.0.0 on pull request 301 / commit c2b83f98 and has been addressed in version 6.0.0 with pull request 445 / commit 21201723d. Users are advised to upgrade. Users unable to upgrade may either check the certificate extracted via getCertFromKeyInfo against trusted certificates before accepting the results of the validation or set xml-crypto's getCertFromKeyInfo to () => undefined forcing xml-crypto to use an explicitly configured publicCert or privateKey for signature verification.

From the GitHub advisory

Summary

Default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a element, and pass xml-crypto default validation checks.

Details

Affected xml-crypto versions between versions >= 4.0.0 and

xml-crypto trusts by default any certificate provided via digitally signed XML document's .

Weakness type: CWE-347.

Product: xml-crypto (npm) · Assigned by: GitHub_M · Published: 2024-05-02

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: none (no login)
• User interaction: none
• Scope: changed (can affect other components)

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation poc, automatable yes, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.83% probability of exploitation activity in the next 30 days; percentile 57.

Timeline

• 2024-05-01 — GitHub-reviewed advisory GHSA-2xp3-57p7-qf4v published (critical)
• 2024-05-02 — CVE record published by GitHub_M
• 2025-02-13 — CVE record last updated

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-2xp3-57p7-qf4v github.com
2. CVE.org record CVE-2024-32962 cve.org
3. NVD entry CVE-2024-32962 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com
4. github.com github.com
5. github.com github.com
6. w3.org w3.org
7. security.netapp.com security.netapp.com
8. github.com github.com

Critical npm advisories · Today’s Security Digest