node-forge CVE-2026-118776

Exploitation requires an application that (1) uses node-forge 1.4.0 or earlier to decrypt attacker-influenced data in CBC or ECB mode (including PKCS#7 EncryptedData/EnvelopedData, PKCS#12, and encrypted private keys) and (2) relies on a successful decipher.finish() as evidence that padding - and therefore the data - is valid. The attacker must be able to modify or supply the ciphertext. Limiting factors: impact is integrity-only (no confidentiality or availability), the vulnerable code path is PKCS#7 unpadding, and because CBC/ECB without a MAC are already malleable the extra capability gained is small; AC:H reflects that the attacker needs ciphertext control and the resulting effect is bounded to silently removing up to four plaintext blocks. The fix does not defend against padding-oracle attacks, so authenticating ciphertext (HMAC) or using AES-GCM remains necessary per the vendor.

This is a genuinely low-priority issue, and the multiple signals agree rather than conflict. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N = 3.7 Low) describes a network-reachable but high-complexity flaw with no confidentiality or availability impact and only Low integrity impact. The vuln.today decision label is 'monitor', the GitHub/vendor severity is LOW, and the vendor itself stresses that CBC and ECB without a MAC are already malleable, so the additional capability this bug grants an attacker is small. No EPSS score and no KEV listing were provided; the input gives no evidence of active exploitation. A proof-of-concept does exist in the vendor's GHSA advisory (a working node-forge snippet plus Wycheproof-derived test vectors), but PoC availability is a distinct signal from exploitation and should not be read as in-the-wild use. The one nuance worth flagging: the vendor also computed a CVSS 4.0 vector of 6.3 (Moderate) because 4.0 weights integrity more heavily, while the authoritative rating follows CVSS 3.1 at Low - so the apparent '3.7 vs 6.3' gap is a scoring-framework difference, not a dispute about impact. Net: a real correctness/integrity defect worth patching on a normal cadence, not an emergency.

An application uses node-forge to decrypt attacker-supplied AES or DES data in CBC or ECB mode and treats a successful decipher.finish() as proof the data was well-formed. An attacker who can modify or submit ciphertext sends a block with malformed PKCS#7 padding (for example a zero count, an oversized count, or mismatched padding bytes); node-forge 1.4.0 accepts it and silently strips up to four trailing plaintext blocks, so the application processes truncated/malformed data as valid. A working proof-of-concept is published in the vendor's GHSA advisory; exploitation complexity is high (AC:H) and impact is limited to integrity.