NODE-FORGE · CVE-2026-119192 · Package
FIX → 1.4.1
node-forge accepted malformed BER encodings of the DigestInfo during RSASSA-PKCS1-v1_5 signature verification. For RSA keys with public exponent e=3, an attacker can forge a signature that verifies as valid without the private key.
first public Nov 10, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that use node-forge to verify RSASSA-PKCS1-v1_5 signatures, including via publicKey.verify(), X.509 certificate chains and PKCS#7 signatures. Exposure requires the verifying RSA public key to have a low public exponent such as e=3; keys with larger exponents are not practically affected according to the advisory.
Not affected if default-exponent-keys, no-rsa-verify, version-1.4.1-or-later
Who cares node-forge, node.js, pkcs7, rsa, x509
npm ls node-forge and confirm it is 1.4.1 or later.publicKey.verify( and X.509 or PKCS#7 verification calls in code that uses node-forge.Upgrade to 1.4.1
RSASSA-PKCS1-v1_5 signature verification (publicKey.verify() with the default scheme, also used by X.509 certificate and PKCS#7 verification) accepted non-canonical BER encodings of the DigestInfo, such as NULL parameters with content and non-minimal lengths. These leave attacker-controlled bytes inside an accepted DigestInfo, which allows signatures to be forged without the private key for RSA keys with a low public exponent (e=3). Fixed in node-forge 1.4.1.
In lib/rsa.js, key.verify() with the default RSASSA-PKCS1-V1_5 scheme removes the padding, parses the recovered DigestInfo with the lenient BER parser asn1.fromDer() and checks its structure with asn1.validate() against digestInfoValidator. Neither requires a canonical DER encoding, so verification accepted, among others:
05 40 <64 bytes>)Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
1.4.1These leave attacker-controlled bytes inside an accepted DigestInfo. For RSA keys with a low public exponent (e=3) this allows signatures to be forged without the private key (BERserk / Bleichenbacher-style forgery, see CVE-2014-1568).
RFC 8017 section 8.2.2 verifies a signature by encoding the expected EMSA-PKCS1-v1_5 message and comparing it with the recovered one; section 9.2 defines the DigestInfo encoding.
The fix adds _encodeDigestInfo(), which DER-encodes the expected DigestInfo from the digest algorithm OID and the digest (with and without NULL parameters). Verification now requires the recovered DigestInfo to match one of these encodings byte for byte. The same change fixes GHSA-2g46-22mc-6gwp (CVE-2026-85393).
Fixed in node-forge 1.4.1. Verification now re-encodes the expected DigestInfo and requires a byte-for-byte match (RFC 8017 section 8.2.2).
Do not use RSA keys with a low public exponent (e=3) for signature verification.
CVSS 3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (7.5, High) CVSS 4.0 (informational): CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N (8.2) Both versions rate this High. The severity rating follows CVSS 3.1.
Independently reported by Oren Yomtov (@orenyomtov, Fireblocks), Bronson Yen (Calif.io, in collaboration with Claude and Anthropic Research), Kamil Hałajda, @pzartech, @antonlissone and @Brechard.
DigestInfo encodings accepted before 1.4.1 (SHA-256; OID = 06 09 60 86 48 01 65 03 04 02 01, H = the 32-byte digest):
NULL parameters with content: 30 33 30 0F <OID> 05 02 BE EF 04 20 <H>
non-minimal DigestInfo length: 30 81 31 30 0D <OID> 05 00 04 20 <H>
(canonical form: 30 31 30 0D <OID> 05 00 04 20 <H>)
Long-form lengths are accepted the same way for the DigestAlgorithm, OID, NULL and digest fields. A signature whose EMSA-PKCS1-v1_5 block (00 01 FF..FF 00 || DigestInfo) contains such an encoding verified as valid: publicKey.verify(digest, signature) returned true. Content bytes in the NULL parameters (reports used e.g. 05 40 <64 bytes>) and similar slack give an attacker room to construct a forged signature for an e=3 key. With 1.4.1, verification throws "ASN.1 object does not contain a valid RSASSA-PKCS1-v1_5 DigestInfo value."
Regression tests: tests/unit/rsa.js, "canonical DigestInfo checks". They use an e=1 key, so the signature equals the encoded block, with one test per non-canonical shape (also indefinite length, constructed and non-NULL parameters, padded OID subidentifiers) and two tests that the canonical encodings with and without NULL parameters still verify. Included in the 1.4.1 release.
Applications that verify RSASSA-PKCS1-v1_5 signatures with node-forge: publicKey.verify() with the default scheme, and X.509 certificate and PKCS#7 signature verification, which use it. If the verifying RSA public key has a low public exponent (e=3), an attacker can forge a signature that verifies as valid, without the private key. Only keys with a small public exponent such as e=3 are practically affected.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.