node-forge prototype pollution/signature verification issue (CVE-2020-7712)

Two of the most consequential flaws ever found in node-forge — the pure-JavaScript crypto library that ships inside thousands of npm dependency trees — allowed attackers to forge valid-looking RSA signatures and, in an earlier release line, pollute JavaScript's global Object.prototype. Tracked as CVE-2022-24771 and CVE-2022-24772 (signature verification bypass) and CVE-2020-7720 (prototype pollution), these issues meant that any application using node-forge to validate X.509 certificates, PKCS#7 messages, PKCS#12 archives, or generic signed payloads could be tricked into treating attacker-controlled data as cryptographically legitimate. Because node-forge is pulled in transitively by build tools, browser polyfills, PDF/certificate utilities, and countless SDKs, most teams running it had no idea it was in their dependency graph at all — let alone that its signature checks could be defeated.

What Went Wrong

node-forge implements TLS-adjacent cryptography (RSA, ASN.1/DER parsing, X.509, PKCS#7, PKCS#12) entirely in JavaScript, without relying on Node's native OpenSSL bindings. That reimplementation is where both bug classes originated.

CVE-2022-24771 / CVE-2022-24772 — RSA PKCS#1 v1.5 signature forgery. Versions of node-forge prior to 1.3.0 were too permissive when verifying RSA PKCS#1 v1.5 signatures against a DigestInfo ASN.1 structure:

• CVE-2022-24771 — the verification code did not strictly validate the structure of the decoded DigestInfo, letting an attacker steal padding bytes to construct a forged signature.
• CVE-2022-24772 — the verifier failed to check for trailing "garbage" bytes appended after the legitimate DigestInfo structure inside the padded message.

Both flaws are variants of the classic Bleichenbacher/Filippo-style RSA signature forgery: when a public key uses a low public exponent (most commonly e=3), an attacker who controls the message can construct a value that, when cubed and truncated, produces a byte string whose prefix matches a validly-encoded DigestInfo for the expected hash — while node-forge's insufficiently strict parser accepts the extra "garbage" bytes that follow instead of rejecting them. The practical effect: an attacker can forge a signature over an arbitrary message without ever holding the private key, as long as the verifying code accepts a low-exponent RSA key and relies on node-forge's pki.verify / signature-checking path. This directly undermines certificate validation, PKCS#7 signed-data verification, and any custom signing scheme built on top of forge.pki.

CVE-2020-7720 — Prototype Pollution. Independently, versions of node-forge before 0.10.0 exposed a util.setPath helper that could be reached with attacker-influenced keys (e.g., __proto__), allowing a caller to write arbitrary properties onto Object.prototype. Depending on how the host application consumed those polluted properties, this could enable denial of service, logic bypasses, or — in the worst case, when combined with other primitives — remote code execution.

It's also worth noting the pattern didn't stop in 2022: in November 2025, researcher Hunter Wodzenski of Palo Alto Networks disclosed CVE-2025-12816, another ASN.1-parsing "interpretation conflict" in node-forge's asn1.validate function that again let crafted structures bypass signature/structure validation, this time affecting versions up to 1.3.1. Signature and ASN.1 parsing correctness has been a recurring soft spot for this library across half a decade of releases.

Affected Versions and Components

Because node-forge is almost always a transitive dependency — pulled in by libraries that generate certificates, sign JWT-like payloads, parse PKCS#12 keystores, or implement TLS-in-JS for environments without native OpenSSL access — application teams frequently don't declare it directly. It has shown up in dependency trees behind build tooling (webpack/Parcel-adjacent packages), Google's google-p12-pem, various certificate-generation utilities, and enterprise platforms such as IBM Maximo, which issued its own advisory after the 2022 disclosures. With roughly 25-26 million weekly npm downloads at the time of the most recent advisory, the practical blast radius of any node-forge signature-verification bug is enormous.

Severity: CVSS, EPSS, and KEV Status

• CVE-2022-24771: CVSS 3.1 base score 7.5 (High) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. CWE-347 (Improper Verification of Cryptographic Signature). Reported EPSS around 29%, notably elevated for a library-level crypto flaw, reflecting how attractive signature-forgery bugs are to exploit-probability models.
• CVE-2022-24772: CVSS 3.1 base score 7.5 (High), same vector and CWE-347 classification, sharing the same root cause and patch commit as CVE-2022-24771.
• CVE-2020-7720: CVSS v3 7.3 (High), CWE-1321 (Prototype Pollution), remotely exploitable with no authentication required.
• KEV status: none of these node-forge CVEs currently appear on CISA's Known Exploited Vulnerabilities catalog. That is not the same as "safe to ignore" — KEV listing requires confirmed in-the-wild exploitation, and signature-forgery bugs in a library this deeply embedded are exactly the kind of issue that can be exploited quietly, well before evidence surfaces publicly.

The combination of a High CVSS score, a well-above-average EPSS probability, and CWE-347's direct hit on cryptographic trust decisions is why security teams treat node-forge signature bugs as priority patches rather than routine dependency bumps.

Timeline

• 2020 — node-forge 0.10.0 ships, removing the vulnerable util.setPath code path; CVE-2020-7720 is subsequently assigned and published to document the Prototype Pollution issue in prior releases.
• March 18, 2022 — Digital Bazaar publishes GitHub Security Advisories GHSA-cfm4-qjh2-4765 and GHSA-x4jg-mjrx-434g alongside node-forge 1.3.0, fixing the RSA PKCS#1 v1.5 verification gaps. CVE-2022-24771 and CVE-2022-24772 are published the same day, prompting vendor bulletins from IBM and others whose products bundled the affected versions.
• 2022-2025 — Downstream ecosystems (Java/webjars mirrors, enterprise platforms, build tooling) issue their own dependent advisories as they update bundled copies of node-forge, illustrating the typical multi-year "long tail" of transitive-dependency patching.
• October 13, 2025 — Digital Bazaar is notified by Palo Alto Networks researcher Hunter Wodzenski of a new ASN.1 validator desynchronization issue.
• November 25-26, 2025 — node-forge 1.3.2 is released, and CVE-2025-12816 / VU#521113 are published, underscoring that signature/ASN.1 validation correctness in this library remains an active area of risk.

Remediation Steps

1. Identify every path node-forge enters your environment. Run npm ls node-forge (or the equivalent for yarn/pnpm) across all services, and don't stop at direct dependencies — check certificate, PKCS#12, JWT, and PDF-signing libraries that commonly wrap it.
2. Upgrade to node-forge ≥ 1.3.2. This single version pulls in the fixes for the 2022 signature-verification issues and the 2025 ASN.1 desynchronization fix. If you're still on a pre-0.10.0 line for any reason, that upgrade also clears CVE-2020-7720.
3. Avoid low-exponent RSA keys where possible, and treat any signature verification built on forge.pki prior to the patched versions as untrustworthy until upgraded — this is not a "defense in depth later" fix, it is a correctness fix for a trust decision.
4. Re-verify previously accepted signatures/certificates if your threat model includes an attacker who may have exploited the window between disclosure and your patch — forged signatures accepted during that window won't be retroactively invalidated by upgrading alone.
5. Pin and monitor. Add node-forge to a dependency watchlist so future advisories (this library has had signature-adjacent issues in 2020, 2022, and 2025) trigger an alert rather than being discovered during an audit.
6. Sanitize before you patch, if you can't patch immediately. For the prototype pollution class specifically, avoid passing untrusted keys (__proto__, constructor, prototype) into any util.setPath-style helper, and consider running with Object.freeze(Object.prototype) as a stopgap in older deployments.

How Safeguard Helps

Safeguard is built to catch exactly this class of risk before it becomes an incident. Our SBOM generation and ingest pipeline surfaces node-forge even when it's buried three or four layers deep in a transitive dependency tree, so you're not relying on a manual npm ls audit to know it's there. Reachability analysis then determines whether your code actually calls into the vulnerable forge.pki signature-verification path or the affected util.setPath helper — separating "technically present" from "actually exploitable" so your team isn't stuck triaging every dependency alert as equally urgent. Griffin AI correlates the CVE, CVSS/EPSS signal, and your specific call paths to prioritize node-forge upgrades against everything else competing for engineering time, and where a safe upgrade path exists, Safeguard opens an auto-fix pull request that bumps node-forge to a patched release and runs your test suite before you ever see it. That turns a multi-CVE library with a five-year history of signature-verification issues into a routine, low-effort remediation instead of a recurring fire drill.