https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 10:42:32 +0000 https://vulnerability.circl.lu/vuln/ghsa-q67f-28xg-22rw <p><strong>Affected:</strong> npm: node-forge</p> <p>## Summary Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (`S &gt;= L`). A valid signature and its `S + L` variant both verify in forge, while Node.js `crypto.verify` (OpenSSL-backed) rejects the `S + L` variant, [as defined by the specification](https://datatracker.ietf.org/doc/html/rfc8032#section-8.4). This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see [CVE-2026-25793](https://nvd.nist.gov/vuln/detail/CVE-2026-25793), [CVE-2022-35961](https://nvd.nist.gov/vuln/detail/CVE-2022-35961)). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed.</p> <p>## Impacted Deployments **Tested commit:** `8e1d527fe8ec2670499068db783172d4fb9012e5` **Affected versions:** tested on v1.3.3 (latest release) and all versions since Ed25519 was implemented.</p> <p>**Configuration assumptions:** - Default forge Ed25519 verify API path (`ed25519.verify(...)`).</p> <p>## Root Cause In `lib/ed25519.js`, `crypto_sign_open(...)` uses the signature&#39;s last 32 bytes (`S`) directly in scalar multiplication:</p> <p>```javascript scalarbase(q, sm.subarray(32)); ```</p> <p>There is no prior check enforcing `S &lt; L` (Ed25519 group order). As a result, equivalent scalar classes can pass verification, including a modified signature where `S := S + L (mod 2^256)` when that value remains non-canonical.…</p> <p><strong>Affected:</strong> npm: node-forge</p> <p>## Summary Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (`S &gt;= L`). A valid signature and its `S + L` variant both verify in forge, while Node.js `crypto.verify` (OpenSSL-backed) rejects the `S + L` variant, [as defined by the specification](https://datatracker.ietf.org/doc/html/rfc8032#section-8.4). This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see [CVE-2026-25793](https://nvd.nist.gov/vuln/detail/CVE-2026-25793), [CVE-2022-35961](https://nvd.nist.gov/vuln/detail/CVE-2022-35961)). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed.</p> <p>## Impacted Deployments **Tested commit:** `8e1d527fe8ec2670499068db783172d4fb9012e5` **Affected versions:** tested on v1.3.3 (latest release) and all versions since Ed25519 was implemented.</p> <p>**Configuration assumptions:** - Default forge Ed25519 verify API path (`ed25519.verify(...)`).</p> <p>## Root Cause In `lib/ed25519.js`, `crypto_sign_open(...)` uses the signature&#39;s last 32 bytes (`S`) directly in scalar multiplication:</p> <p>```javascript scalarbase(q, sm.subarray(32)); ```</p> <p>There is no prior check enforcing `S &lt; L` (Ed25519 group order). As a result, equivalent scalar classes can pass verification, including a modified signature where `S := S + L (mod 2^256)` when that value remains non-canonical.…</p> https://vulnerability.circl.lu/vuln/ghsa-q67f-28xg-22rw