Loading vulnerability…
CVE-2024-32962 affects the Node.js xml-crypto XML digital signature and encryption library. In affected versions, the default verification behavior validates the cryptographic correctness of an XML signature but does not properly authorize the signer. Specifically, the library trusts certificates supplied in the signed XML document's <KeyInfo /> element by default and prefers that embedded certificate even when the application has configured a specific verification certificate via publicCert. This allows an attacker to modify a signed XML document, replace the original signature with a new signature created using an attacker-controlled private key, embed the corresponding certificate in <KeyInfo />, and still pass default xml-crypto validation. The issue stems from behavior introduced in 4.0.0 and was fixed in 6.0.0. The vulnerability is effectively an improper signature verification / trust decision flaw in which signature validity is checked without adequately binding trust to an authorized certificate or identity.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
xml-crypto validation semantics to accept attacker-modified XML as legitimately signed. Depending on how signed XML is used by the consuming application, this can lead to integrity compromise, authentication or authorization bypass, acceptance of forged assertions or messages, and downstream business-logic abuse. The core impact is not arbitrary code execution, but false trust in attacker-controlled signed content.If you can’t patch tonight, do this now.
getCertFromKeyInfo against a trusted certificate set before accepting signature verification results, or set getCertFromKeyInfo to () => undefined so that xml-crypto ignores certificates embedded in <KeyInfo /> and instead uses an explicitly configured publicCert or privateKey for verification. More generally, treat <KeyInfo /> as untrusted input unless it is explicitly matched against a trusted identity or certificate store.Patch, then assume compromise.
xml-crypto to version 6.0.0 or later, where the vulnerable certificate-selection and trust behavior has been addressed. Review all code paths that rely on default signature validation behavior and ensure verification is performed against explicitly trusted certificates or trust anchors rather than certificates embedded in untrusted XML input. If signed XML is used in security-sensitive workflows such as SSO, message authentication, or authorization decisions, revalidate the trust model and test that attacker-supplied <KeyInfo /> certificates are not accepted.No valid public exploits. Mallory filtered out 1 candidate as fakes, detection scripts, or README-only repos.
All candidate exploits were filtered out by Mallory's validation.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
2 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.