node-forge Vulnerabilities: What Happened and What to Use Now

node forge — published on npm as node-forge — is a pure-JavaScript crypto and TLS toolkit with a real vulnerability history, and the most serious entries were RSA signature-forgery bugs fixed in version 1.3.0. If you have it in your dependency tree today (and you probably do, transitively), the questions that matter are: are you on 1.3.1 or later, do you actually exercise the vulnerable code paths, and should new code be using it at all. This post walks through the notable advisories, what each one allowed an attacker to do, and where the JavaScript ecosystem has moved since.

What node-forge is and why it's everywhere

Forge, maintained under the Digital Bazaar GitHub organization, implements TLS, X.509 certificate handling, RSA, ASN.1 parsing, and a stack of hashing and encoding utilities entirely in JavaScript. That made it invaluable in the years before the Web Crypto API and before Node's crypto module covered certificate workflows: it could generate a self-signed certificate in the browser, parse a PKCS#12 bundle in a build script, or verify a signature in an environment with no native OpenSSL bindings.

That utility is exactly why it spread. Dev servers used it to mint local HTTPS certificates, PDF and document-signing libraries embedded it, and countless tools pulled it in three or four levels deep. Run npm ls node-forge in a mature project and there is a fair chance it appears somewhere you never asked for it.

The RSA signature verification flaws (CVE-2022-24771 and CVE-2022-24772)

The most consequential node-forge vulnerability disclosures landed in March 2022, both in the RSA PKCS#1 v1.5 signature verification code, and both fixed in release 1.3.0.

CVE-2022-24771 (rated High) described verification code that was lenient in checking the digest algorithm structure inside the decoded signature. A crafted ASN.1 structure could steal padding bytes and use the unchecked portion of the PKCS#1 encoded message to forge a signature — provided the key used a low public exponent such as 3.

CVE-2022-24772 (rated Medium) was the sibling issue: the verifier did not check for trailing garbage bytes after decoding the DigestInfo ASN.1 structure, again enabling forgery against low-exponent keys.

Both are variants of the classic Bleichenbacher signature-forgery technique from 2006. The practical impact depends on your usage: if node-forge only generates throwaway dev certificates, exposure is minimal. If it verifies signatures on data an attacker can supply — license files, signed tokens, plugin manifests — a forgery bug is about as bad as crypto bugs get. The 1.3.0 fix added a strict validator for the RSASSA-PKCS-v1_5 DigestInfo structure and made unknown algorithm identifiers throw.

The prototype pollution bug (CVE-2020-7720)

Before the signature issues, CVE-2020-7720 reported that forge.util.setPath allowed prototype pollution: attacker-influenced path segments like __proto__ could write properties onto Object.prototype, with the usual downstream consequences ranging from denial of service to, in unlucky applications, code execution. The fix in version 0.10.0 was blunt and correct — the vulnerable utility functions were removed outright as a breaking change.

This one is a useful reminder that a crypto library's attack surface is not only its crypto. Utility helpers shipped alongside the primitives count too, and they are exactly the kind of code that transitive consumers invoke without reading.

Where the project stands today

The current release is 1.3.1, which followed the 1.3.0 security release in March 2022. Since then the release cadence has essentially stopped. The package still sees enormous download volume because so many older tools depend on it, but "widely downloaded" and "actively developed" are different properties, and conflating them is one of the most common dependency-review mistakes. Our post on abandoned open source project risks covers why a quiet repository under millions of dependents deserves a closer look, not a pass.

To be fair to the maintainers: 1.3.1 contains fixes for every advisory discussed above, and no unfixed high-severity issue is publicly known against it as of this writing. The risk is forward-looking — a low-activity crypto library is a poor foundation for new code, because the next parser bug in hand-rolled ASN.1 handling has no guaranteed responder.

What to use instead for new code

For most tasks node-forge historically handled, the platform has caught up:

• Hashing, HMAC, AES, RSA/ECDSA sign and verify: the Web Crypto API (crypto.subtle) is available in every modern browser and in Node.js via globalThis.crypto. It runs native, audited implementations rather than JavaScript bignum arithmetic.
• JWTs, JWS, JWE, JWK: the jose package is actively maintained and built on Web Crypto.
• X.509 parsing and certificate generation: @peculiar/x509 provides a modern, Web Crypto-backed API; on the server, Node's own crypto.X509Certificate covers inspection.
• TLS: in Node, use the built-in tls module. A userland TLS stack in JavaScript is very hard to justify in 2025.

A minimal Web Crypto verification, for comparison:

const ok = await crypto.subtle.verify(
  { name: "RSASSA-PKCS1-v1_5" },
  publicKey,
  signatureBuffer,
  dataBuffer
);

The signature-forgery class that hit node-forge is exactly the kind of bug you inherit less often when the padding checks live in the platform's native crypto layer rather than in a dependency you have to keep patched.

Auditing your tree for it

Finding out whether you are exposed takes two commands:

npm ls node-forge
npm audit

Then check the version. Anything at or above 1.3.1 has the known fixes; anything below 1.3.0 should be treated as urgent if signature verification is in play, since public advisories double as exploitation documentation. Because node-forge is usually a transitive dependency, the fix is often an overrides entry in package.json rather than a direct bump:

{
  "overrides": {
    "node-forge": "^1.3.1"
  }
}

Version-matching alone will overstate your exposure, though — a dev-server certificate generator and a production license verifier carry very different risk for the same CVE. An SCA tool such as Safeguard can map where node-forge sits in your graph and flag which advisories are reachable from code you actually ship, which is the difference between one targeted override and a week of undirected upgrade churn.

FAQ

Is node-forge safe to use right now?

Version 1.3.1 has no publicly known unfixed high-severity vulnerabilities. The concern is maintenance trajectory: releases have been rare since 2022, so treat it as acceptable in existing pinned trees but a weak choice for new code, especially for signature verification of attacker-supplied data.

Which node-forge versions are affected by the RSA forgery CVEs?

CVE-2022-24771 and CVE-2022-24772 affect versions before 1.3.0. Both require the verifying key to use a low public exponent (such as 3) to be practically exploitable, and both were fixed in the 1.3.0 release.

What replaced node-forge for most use cases?

The Web Crypto API for primitives, jose for JWT/JOSE workflows, @peculiar/x509 for certificate handling, and Node's built-in crypto and tls modules on the server. All run native or platform-maintained implementations.

How do I know if a transitive node-forge copy is exploitable in my app?

Check the installed version with npm ls node-forge, then determine whether the dependent package calls signature verification or util.setPath-style helpers on untrusted input. Reachability-aware SCA automates that second step; version matching alone cannot answer it.