Crafted PKCS#12 files pass node-forge password checks with any password
An attacker who does not know a password can alter a PKCS#12 file and still make node-forge accept it as valid under that password, GitHub’s advisory says. The file’s integrity check collapses to a constant key.
- Affected
- node-forge <= 1.4.0 (digitalbazaar/forge < 1.4.1)
- Fixed
- node-forge 1.4.1 (digitalbazaar/forge 1.4.1)
Applications that import untrusted PKCS#12/PFX files or PKCS#8 encrypted private keys and treat a successful MAC check or decryption as proof of authorship are exposed. The same flaw reaches shrouded key bags, encrypted SafeContents, and ENCRYPTED PRIVATE KEY PEM input using TripleDES or 40-bit RC2 PKCS#12 PBE; PBES2/PBKDF2 content is not affected.
node-forge 1.4.1 rejects MAC and key-derivation iteration counts below 1. Users should upgrade to 1.4.1; before processing, inputs with MacData.iterations below 1 can also be rejected. The advisory provides a proof of concept but does not establish in-the-wild exploitation.
Sources & technical scope 2 sources
GitHub Advisory Database — original source ↗
GitHub_M CNA / CVE Program — original source ↗
Affected: node-forge <= 1.4.0 (digitalbazaar/forge < 1.4.1)
Fixed: node-forge 1.4.1 (digitalbazaar/forge 1.4.1)
Exploitation: Supplied evidence includes a proof of concept but does not establish known in-the-wild exploitation.
Scope & limitations: Whether downstream applications consume attacker-controlled PKCS#12 input and any exploitation telemetry are not established by the supplied evidence.
External findings belong to the credited researchers.