{"vuid":"VU#725167","idnumber":"725167","name":"node-forge Signature Forgery Vulnerabilities in RSA-PKCS and ED25519 Implementations","keywords":null,"overview":"### Overview  \r\nTwo distinct cryptographic signature verification vulnerabilities exist in Digital Bazaar node-forge, a widely used JavaScript library implementing cryptographic primitives for Node.js and browser environments. These vulnerabilities allow attackers to forge RSA (PKCS#1 v1.5) and Ed25519 signatures under specific, exploitable conditions.  \r\n\r\n### Description \r\nBoth vulnerabilities stem from insufficient enforcement of canonical cryptographic structures during verification: in the RSA case, non-standard ASN.1 encodings and undersized padding are accepted; in the Ed25519 case, non-canonical signature scalars are not rejected. As a result, node-forge accepts signatures that appear valid internally but are rejected by industry-standard libraries such as OpenSSL and Node.js’s native crypto module.  \r\n\r\nThe vulnerabilities affect node-forge versions 0.1.2 through 1.3.3 for RSA-PKCS#1 v1.5, and 0.7.4 through 1.3.3 for Ed25519. Both issues were resolved in v1.4.0, released on 2026-04-05.\r\n\r\n**CVE-2026-33894** arises in `lib/rsa.js`, where RSASSA-PKCS1-v1_5 verification accepts forged signatures due to two related flaws. First, the ASN.1 parser for `DigestInfo` permits non-canonical encodings—specifically, structures with more than the two required fields (algorithm OID and octet string), including attacker-controlled additional data. Second, the PKCS#1 v1.5 decoding logic fails to enforce the RFC 2313 requirement that the padding string (`PS`) must be *at least 8 bytes*. These combined weaknesses enable attackers to construct specially crafted signatures, particularly with low public exponents (e.g., `e = 3`), that node-forge validates successfully while standard implementations correctly reject them.\r\n\r\n**CVE-2026-33895** resides in `lib/ed25519.js`, where signature verification does not enforce scalar canonicality as mandated by RFC 8032. The scalar `S` (last 32 bytes of the signature) is used without ensuring it lies within the valid range `[0, L−1]`, where `L` is the Ed25519 group order. Consequently, signatures with `S′ = S + k·L` (e.g., `S + L`) verify as valid in `node-forge`, even though canonical implementations such as Node.js crypto and OpenSSL reject them. This undermines assumptions about signature uniqueness and enables substitution attacks in systems relying on strict byte-for-byte signature validity—for instance, audit logs, token binding, or attestation protocols.\r\n\r\n### Impact  \r\nThe most immediate concern is integrity: attackers may forge signatures for arbitrary messages in the RSA case or mutate valid Ed25519 signatures in ways that remain accepted by node-forge. Such forgery enables bypassing authentication, code-signing, or session-bound token validations, especially in workflows where `node-forge` is used as the sole verification engine.\r\n\r\nThe scope is broad. Any application using node-forge’s default verification APIs—including JOSE libraries like node-jose, certificate tooling from Adobe and Expo, and custom PKI integrations—is potentially affected. Because the vulnerabilities manifest in the default configuration (i.e., no unusual flags or options required), unpatched deployments face exposure without any operator action.\r\n\r\nExploitation is straightforward. Public proofs of concept demonstrate RSA forgery with low-exponent keys and Ed25519 scalar manipulation with minimal effort, and both attacks work over the network against remote endpoints performing verification.\r\n\r\n### Solution  \r\nThe vulnerabilities have been fully addressed in node-forge v1.4.0, released on 2026-04-05. This release enforces strict canonical validation: RSA verification now rejects non-canonical DigestInfo structures and enforces PS greater than or equal to 8 bytes of padding, while Ed25519 verification explicitly checks that `S < L`.  \r\n\r\nAfter upgrading, users can verify the fix by running the included test suite, which includes dedicated test cases for both CVEs.  \r\n\r\nIf you maintain downstream packages that depend on node-forge, update your dependency lockfiles and test thoroughly with v1.4.0 before releasing. Even indirect usage through frameworks, build tools, or security plugins may expose your users to risk until the transitive dependency is upgraded.\r\n\r\n#### Mitigations\r\nIf immediate upgrade is not possible due to legacy dependencies or indirect usage in transitive dependencies, the following interim measures are recommended:\r\n1. Audit all call sites invoking `forge.pki.publicKey.verify()`, `ed25519.verify()`, or JOSE-based verification routes. \r\n2. Where feasible, fall back to Node.js native crypto.verify() for RSA and Ed25519 validation, particularly in high-assurance flows such as code signing or identity assertion. \r\n3. In critical workflows, consider implementing cross-library verification: for instance, compute the signature with node-forge but validate it using the Node.js crypto module as a secondary check.  \r\n\r\nIt is important to note that options such as` _parseAllDigestBytes: true` do not mitigate these vulnerabilities, as they neither enforce ASN.1 strictness nor padding length. Relying on them may create a false sense of security.  \r\n\r\n### Acknowledgements  \r\nThis vulnerability was discovered by Austin Chu, Sohee Kim, and Corban Villa, of the University of California, Berkeley, as part of a security research project. This AI-assisted vulnerability note was prepared by Timur Snoke.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://datatracker.ietf.org/doc/html/rfc2313#section-8","https://datatracker.ietf.org/doc/html/rfc8032#section-8.4","https://github.com/digitalbazaar/forge/security/advisories/GHSA-ppp5-5v6c-4jwp","https://github.com/digitalbazaar/forge/security/advisories/GHSA-q67f-28xg-22rw"],"cveids":["CVE-2026-33895","CVE-2026-33894"],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-07-15T16:07:29.935463Z","publicdate":"2026-07-15T16:07:29.751876Z","datefirstpublished":"2026-07-15T16:07:29.953473Z","dateupdated":"2026-07-15T16:24:29.038823Z","revision":2,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":217}