CISA updates node-forge for signature forgery flaws in RSA-PKCS#1 and Ed25519
3 companies named across 2 categories, one of 13 articles referencing Node.js. Previous coverage: CISA issues guidance on Terrarium CVE-2026-5752 sandbox escape (Apr 2026).
Companies mentioned
Best suited for
- Seniority
- C Level / Executive Team
- Job function
- Chief Information Security Officer
- Persona
- Security Architect
- Buyer role
- Decision Maker / Budget Holder
- Decision stage
- Which to buy
- Adoption curve
- Late Majority
- Technology maturity
- Established Technology
- Industry
- Information Technology / Software & Services / IT Services / Data Processing & Outsourced Services
Our classification, not the publisher's statement. Best suited for, not only for.
Digital Bazaar node-forge contains two cryptographic signature verification vulnerabilities that can enable signature forgery for RSA (PKCS#1 v1.5) and Ed25519. The most direct impact is loss of integrity, including the ability to bypass verification paths that rely on node-forge as the verification engine.
CVE-2026-33894 affects node-forge versions 0.1.2 through 1.3.3 for RSA-PKCS#1 v1.5 and is in lib/rsa.js. It involves RSASSA-PKCS1-v1_5 verification accepting forged signatures due to a DigestInfo ASN.1 parser that permits non-canonical encodings, including attacker-controlled additional data in structures with more than the two required fields (algorithm OID and octet string), and PKCS#1 v1.5 decoding logic that does not enforce the RFC 2313 requirement that the padding string (PS) must be at least 8 bytes; the note states that attackers can construct specially crafted signatures, particularly with low public exponents such as e = 3, which node-forge validates while standard implementations correctly reject. CVE-2026-33895 affects node-forge versions 0.7.4 through 1.3.3 for Ed25519 and is in lib/ed25519.js. It states that signature verification does not enforce scalar canonicality as mandated by RFC 8032, because the scalar S (last 32 bytes of the signature) is used without ensuring it lies within [0, L−1], where L is the Ed25519 group order; it also states that signatures with S′ = S + k·L (for example, S + L) verify as valid in node-forge while Node.js crypto and OpenSSL reject them.
For the RSA case, the immediate concern is integrity, because attackers may forge signatures for arbitrary messages; for the Ed25519 case, attackers may mutate valid signatures in ways that remain accepted by node-forge. The guidance also states that such forgery can enable bypassing authentication, code-signing, or session-bound token validations, especially in workflows where node-forge is the sole verification engine. It further states that the scope can cover applications using node-forge default verification APIs, including JOSE libraries like node-jose, certificate tooling from Adobe and Expo, and custom PKI integrations, with exposure occurring in unpatched deployments due to default configuration. It also states that exploitation is straightforward, with public proofs of concept demonstrating RSA forgery with low-exponent keys and Ed25519 scalar manipulation, and that both attacks work over the network against remote endpoints performing verification.
The vulnerabilities are fully addressed in node-forge v1.4.0, released on 2026-04-05. The note states that the fix enforces strict canonical validation: RSA verification rejects non-canonical DigestInfo structures and enforces PS greater than or equal to 8 bytes of padding, and Ed25519 verification explicitly checks that S < L. It also states that the fix can be verified by running the included test suite, which includes dedicated test cases for both CVEs.
The note recommends that downstream packages update dependency lockfiles and test with v1.4.0 before releasing, including cases where node-forge is used indirectly through frameworks, build tools, or security plugins until the transitive dependency is upgraded. For interim measures when upgrade is not possible, it states that options such as _parseAllDigestBytes: true do not mitigate the vulnerabilities. The note then recommends auditing call sites invoking forge.pki.publicKey.verify(), ed25519.verify(), or JOSE-based verification routes, and where feasible falling back to Node.js native crypto.verify() for RSA and Ed25519 validation, particularly in high-assurance flows such as code signing or identity assertion. It also recommends implementing cross-library verification in critical workflows by computing the signature with node-forge but validating it using the Node.js crypto module as a secondary check.
Blog post, originally published at kb.cert.org.