Overview Two 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. Description Both 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. The 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. 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. 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. Impact The 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. The 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. Exploitation 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. Solution The 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 . After upgrading, users can verify the fix by running the included test suite, which includes dedicated test cases for both CVEs. If 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. Mitigations If immediate upgrade is not possible due to legacy dependencies or indirect usage in transitive dependencies, the following interim measures are recommended: 1. Audit all call sites invoking forge.pki.publicKey.verify() , ed25519.verify() , or JOSE-based verification routes. 2. 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. 3. 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. It 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. Acknowledgements This 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. Vendor Information One or more vendors are listed for this advisory. Please reference the full report for more information. References 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 Other Information CVE IDs: CVE-2026-33894 CVE-2026-33895 Date Public: 2026-07-15 Date First Published: 2026-07-15 Date Last Updated: 2026-07-15 16:24 UTC Document Revision: 2 About vulnerability notes Contact us about this vulnerability Provide a vendor statement