Signature forgery flaws in node-forge, a JS crypto library with 34M weekly downloads (CVE-2026-33894, CVE-2026-33895): update to 1.4.0

Two flaws that let signature checks be bypassed have been found in "node-forge," a JavaScript cryptography library used in apps worldwide. The problem is that a "forged signature" crafted by an attacker can be accepted by node-forge as genuine. Japan's vulnerability portal JVN (JVNVU#98998987) and the U.S. CERT/CC advisory (VU#725167) disclosed them on July 16, 2026.

node-forge is downloaded about 34.4 million times per week, making it one of the most widely used cryptography libraries in the JavaScript world. Even if you don't use it directly, it is often pulled in without you noticing as part of another library. The fixed node-forge 1.4.0 is already available, and the fix is simply to update. This article walks through what happens, how to check whether your app is affected, and how to update.

What node-forge is, and why it matters to so many

node-forge is a library (component) that lets you perform "computations for safety" — encryption, digital signatures, certificate handling — entirely in JavaScript. Developed by Digital Bazaar, it is used across a wide range of tasks: encrypting passwords, protecting communications, verifying certificates, and checking digital signatures.

What matters is how widely it is spread. node-forge is depended on by a huge number of packages, so even if your app doesn't call node-forge directly, another library you use very often calls it internally. CERT/CC's advisory reports that the same class of flaw was confirmed across multiple implementations, including node-jose (a token-handling library), Expo, and Adobe's certificate tools.

In other words, even developers and companies who think "I never touch cryptography" can be affected if they run a Node.js app. That is why this flaw should be treated as broad in reach. It is a textbook case of the "supply chain" problem, where open-source components get embedded into other software one after another. Our OSS Supply Chain Scanner also covers the danger of these indirect dependencies.

What happened: the two signature-forgery flaws

Both flaws are about weak checking of "whether a digital signature is valid." A digital signature is a mechanism that proves data is genuine and unaltered. The receiver verifies the signature to decide it is "certainly legitimate." If there is a gap in that verification, a forged signature can be mistaken for a real one. Here is an overview.

CVE-2026-33894: forging RSA signatures by mixing in "garbage"

The first flaw, CVE-2026-33894, is in RSA signature verification. node-forge did not strictly check the content of the signature data, so it accepted forged signatures that stuffed unrelated "garbage" bytes into gaps of the required format. Depending on the key settings (for example, a small public exponent), an attacker can assemble a forged signature without holding the real private key. The severity is CVSS 7.5 (High), with the loss of data integrity (that it is unaltered) being the core concern. This technique is a classic weakness that has repeatedly turned up in various crypto software over the years.

CVE-2026-33895: allowing a "different look" for Ed25519 signatures

The second flaw, CVE-2026-33895, is in verification for the newer Ed25519 scheme. A valid signature should only use numbers within a defined range, but node-forge did not check that range and accepted "non-canonical signatures" using out-of-range numbers. This creates a problem where multiple signatures that look different but mean the same thing all become valid (signature malleability). It can be abused to slip past authentication decisions, or to confuse mechanisms that use the signature itself as an identifier (deduplication or replay protection). The severity is again CVSS 7.5 (High).

Why signature forgery is dangerous

"Weak signature verification" may not sound alarming, but it means the "identity check" of the electronic world can be bypassed. Here is who could abuse it and how.

The people who can exploit it are attackers who can craft a forged signature and send it into an app. They attach a "plausible fake signature" to a fraudulent login token, a fake certificate, or tampered data, and try to make it appear legitimate.

By exploiting the flaw, an attacker can assemble a forged signature that passes node-forge's verification, and get a fake login, a fake certificate, or tampered data accepted as "legitimate" when it should have been rejected. Decisions that form the foundation of security — authentication, access-control checks, and confirming that distributed programs are genuine (code signing) — can collapse.

For end users, the damage translates to "unauthorized login or data tampering through impersonation." For the companies running the systems, it means "letting malicious access through, mistaking it for legitimate." No real-world abuse has been observed yet, but because signature verification sits at the core of many systems, closing the hole with an update matters.

Is your app affected?

You are affected if you use node-forge 1.3.3 or earlier and perform RSA or Ed25519 signature verification. As noted, though, it may be pulled in indirectly even if you don't use it directly. Use the table and the check below.

To see whether your project uses node-forge (even indirectly), run npm ls node-forge in your project folder. If the version shown is earlier than 1.4.0, you are affected — and the output also traces which library pulls it in. npm audit will also flag it as a known vulnerability.

Severity and real-world risk

Both flaws score 7.5 out of 10 on CVSS, classed as "High." They are not "Critical" (9.0+), but because they touch signature verification — the very foundation of safety — they warrant higher priority than a medium-severity flaw. At the same time, no sign of real-world attacks has been observed, and they are not on the U.S. CISA list of vulnerabilities being actively exploited ("KEV"). There is no need to overreact, but this is not something to leave alone either.

Note that the actual risk depends heavily on how you use node-forge. The RSA forgery (CVE-2026-33894) becomes easier depending on the verification key's settings (such as a small public exponent). The Ed25519 malleability (CVE-2026-33895) matters when you use the appearance of the signature itself as an identifier. Checking which signature scheme your system verifies, and for what purpose, makes it easier to judge priority.

The fix: update node-forge to 1.4.0 or later

The fix is to bring node-forge up to 1.4.0 or later, which patches both signature-verification flaws (the same release also fixes a separate issue with certificate constraint checking). Here is how to proceed.

• If it is a direct dependency, update with npm install node-forge@^1.4.0
• If it is indirect, update the parent library that uses node-forge, or force 1.4.0+ via overrides in package.json
• After updating, run npm ls node-forge to confirm every dependency is now 1.4.0 or later
• Before shipping to production, test your signature-verification paths to confirm that legitimate signatures still pass

Also, other libraries that use node-forge indirectly (such as node-jose) may still bundle an old node-forge internally. Beyond your project's own node-forge, it is important to align the entire dependency tree to 1.4.0 or later.

A technical look: why forgery was possible

CVE-2026-33894 (RSA) stems from loose checking of the "ASN.1" structure that represents the signature. In RSA's PKCS#1 v1.5 scheme, a signature must contain padding of at least a certain length (8 bytes or more) followed by a defined block of information (DigestInfo). node-forge did not enforce the padding length and allowed extra data mixed in. With small keys such as a public exponent of 3, an attacker can adjust and stuff numbers into that gap to craft a signature that passes verification without the private key. The fix enforces the minimum padding length and accepts only the correct DigestInfo form, rejecting extra data.

CVE-2026-33895 (Ed25519) stems from not checking that the number "S" in the latter half of the signature falls within its defined range (0 or greater, and less than the group order L). Because out-of-range values (of the form S + k×L) still passed verification computationally, multiple signatures with the same meaning could exist. The fix adds a function that verifies S is within range and rejects out-of-range signatures. Both fixes are documented in the developer's security advisories.

Who found it, and how far it reaches

These two flaws were found and reported by a security research team at the University of California, Berkeley (Austin Chu, Sohee Kim, and Corban Villa). The team investigated the same kind of weak signature verification not just in node-forge but across multiple crypto implementations, and CERT/CC coordinated and published them together.

CERT/CC's advisory reports that the same weakness was confirmed in the token-handling library node-jose, the app development platform Expo, and Adobe's certificate tools, among others. node-forge itself released the fixed 1.4.0 in April 2026, but this JVN and CERT/CC disclosure broadens the call to attention to include related implementations. It is worth also checking whether a library you use appears on the affected list.

Frequently asked questions

Q. I don't use node-forge directly. Does this still concern me?

A. It may. node-forge is used inside many other libraries, so it is often pulled in indirectly. Run npm ls node-forge to check whether it is included in your project.

Q. Should I update right away?

A. No real-world abuse has been observed yet, but the severity is "High" and it touches signature verification at the core of security. Prioritize it over medium-severity flaws and update to 1.4.0 or later promptly. Priority is especially high if you use node-forge to verify auth tokens, certificates, or code signatures.

Q. Will updating break my existing signatures?

A. Correctly formed, legitimate signatures continue to pass. What the fix rejects are malformed signatures that don't follow the spec. To be safe, test your signature paths before shipping to production.

Q. A scanner warned me about it.

A. Tools like npm audit flag it as a known vulnerability. Aligning node-forge to 1.4.0 or later resolves it. For indirect dependencies, update the parent library or use an override.

Summary

Two flaws that let signature checks be bypassed (CVE-2026-33894 and CVE-2026-33895) were found in node-forge, a cryptography library downloaded about 34.4 million times per week. An attacker's forged signature could be mistaken for a real one, affecting the foundations of security such as authentication and code signing. Both are "High" (CVSS 7.5); no real-world abuse has been observed, but this is not something to leave unpatched.

The fix is to update node-forge to 1.4.0 or later. Because it is often pulled in through other libraries even if you don't use it directly, run npm ls node-forge to inspect the whole dependency tree and align any old versions. In an era where open source is embedded into other software one layer after another, knowing "what you depend on" is your best defense.

Sources

• ▸ JVNVU#98998987 - Multiple signature verification flaws in the JavaScript library Forge (July 16, 2026)
• ▸ CERT/CC VU#725167 - Signature Forgery Vulnerabilities in RSA-PKCS and ED25519 Implementations
• ▸ node-forge Security Advisory - RSA-PKCS signature forgery (CVE-2026-33894) (March 24, 2026)
• ▸ node-forge Security Advisory - Ed25519 signature forgery (CVE-2026-33895) (March 24, 2026)
• ▸ npm - node-forge