node-forge CVE-2026-85393

Exploitation requires two specific conditions: (1) the RSA key used for signature verification must have a low public exponent, specifically e=3 (or comparably small values); e=65537 keys are not exploitable via this cube-root path. (2) The verifying code must invoke key.verify() through node-forge with the default _parseAllDigestBytes: true setting and must accept the signature as authoritative for authentication or integrity decisions. The exploit is unauthenticated (PR:N) and requires no user interaction once a verification endpoint is reachable. Limiting factors: the e=3 key requirement substantially reduces the exposed population to legacy systems, embedded deployments, or scenarios where an attacker can influence key selection; modern tooling defaults to e=65537 which is not affected by the cube-root construction described.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H) rates this 8.7, and the integrity-only, unauthenticated, network-accessible framing is directionally correct. However, AC:L/AT:N understates the key configuration dependency: exploitation strictly requires a low public exponent (e=3) on the RSA key being verified. In practice, modern RSA keys overwhelmingly use e=65537, so the realistic exposed surface is narrower than the raw vector implies. That said, deployments using node-forge to verify JWTs, TLS certificates, or code signatures generated with legacy e=3 keys (or where an attacker controls key generation) are genuinely at risk of authentication bypass or privilege escalation. A working PoC demonstrating cube-root forgery on a 4096-bit e=3 keypair is documented in GHSA-ppp5-5v6c-4jwp, confirming the attack is reproducible. No KEV listing was identified; EPSS data was not supplied. The conflict between the GHSA's 'fixed in: 1.4.0' attribution and the CVE's explicit 'through 1.4.0' scope is a material uncertainty: if no post-1.4.0 fix exists, the entire installed base remains exposed.

An attacker targeting a web application that uses node-forge to verify RSA-signed JWTs with an e=3 key constructs a forged signature by computing the cube root of a specially padded DigestInfo block containing garbage ASN.1 bytes inside the DigestAlgorithm sequence. The forged signature passes node-forge's key.verify() check (which accepts the extra bytes) while encoding an arbitrary digest value, allowing the attacker to produce a self-signed token claiming administrative privileges without possessing the private key. A working PoC demonstrating this against a fresh 4096-bit e=3 keypair is documented in GHSA-ppp5-5v6c-4jwp.