CVE-2024-32962
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedxml-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 `<KeyInfo />` 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 `<KeyInfo />`. `xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` 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 `<KeyInfo />` 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe xml-crypto library for Node.js by default trusts any certificate provided in the `<KeyInfo />` element of signed XML documents without validating the signer's authorization. Even when a specific `publicCert` is configured for verification, the library prioritizes certificates found in the XML document's `<KeyInfo />` over the configured one, allowing attackers to spoof signature verification by re-signing documents with their own malicious private key and certificate.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify xml-crypto installation and versionRun 'npm list xml-crypto' in the project directory, or inspect package.json dependencies, or check node_modules/xml-crypto/package.json for the version fieldAffected if The installed version is below 6.0.0 (or if version cannot be determined but xml-crypto is present)
-
Locate XML signature verification codeSearch codebase for calls to xml-crypto APIs such as 'SignedXml', 'verify', or methods that perform signature validation on XML documentsAffected if The application performs XML signature verification using xml-crypto
-
Inspect getCertFromKeyInfo configurationSearch for 'getCertFromKeyInfo' in the codebase and examine how it is set in the SignedXml configuration objectAffected if getCertFromKeyInfo is not set to '() => undefined' and no custom validation against a trusted certificate store is implemented
-
Check if publicCert is explicitly configured for verificationSearch for 'publicCert' usage in SignedXml initialization and verify whether it is being used as the trusted certificateAffected if publicCert is not set or the certificate from KeyInfo is being trusted over the explicitly configured publicCert
-
Determine if XML documents from untrusted sources are processedReview the data flow to see if the application accepts and verifies signed XML from external or untrusted sourcesAffected if The application processes signed XML from external or untrusted sources without additional certificate validation
You are affected if xml-crypto below version 6.0.0 is used to verify XML signatures and the application relies on certificates from KeyInfo elements without additional validation against a trusted certificate store.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade xml-crypto to version 6.0.0 or later; alternatively, either validate certificates from `getCertFromKeyInfo` against a trusted certificate store before accepting validation results, or set `getCertFromKeyInfo` to `() => undefined` to force use of the explicitly configured `publicCert`.
xml-crypto version 6.0.0
- Upgrade xml-crypto to version 6.0.0 or later using your package manager (e.g., npm install xml-crypto@^6.0.0 or yarn upgrade xml-crypto@^6.0.0)
- After upgrading, verify that your signature validation still works correctly by running existing test suites or manual validation tests
- If you encounter issues, review the changelog for breaking changes between your current version and 6.0.0
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation1.0 h
- Implementation2.0 h
- Testing2.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,664.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2024-32962 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2024-32962 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data