CVE-2026-125335

### Summary `ed25519.verify()` does not reject public keys of small order, such as the identity point. Under such a key, a signature with `S = 0` and a small-order `R` verifies for many messages, or for every message with the identity key, without any private key. Fixed in node-forge 1.4.3. ### Details `crypto_sign_open()` in `lib/ed25519.js` decodes the public key `A` with `unpackneg()`, which only checks that the point is on the curve, and then checks `R == [S]B - [k]A` with `k = SHA-512(R || A || M)`. Nothing rejects public keys of small order: the identity point, the other 7 points of order 2, 4 or 8, and their non-canonical encodings with `y >= p`. With `S = 0`, the check becomes `R == [k](-A)`. For a small-order `A`, `[k](-A)` is one of at most 8 small-order points, so an attacker can make a valid signature by trying the small-order values of `R`. For the identity key (`01 00 … 00`), `R = identity` and `S = 0` verifies for every message. For the other small-order keys, a given message can be forged with high probability. No private key is involved. The `S < L` check added for CVE-2026-33895 (GHSA-q67f-28xg-22rw) doesn't apply, because `S = 0` is canonical. Keys produced by Ed25519 key generation (`ed25519.generateKeyPair()` or any RFC 8032 implementation) are never small-order, so signatures under them cannot be forged this way. Applications are affected when they verify signatures against a public key an attacker can choose (for example a key included with the signed data, a self-registered key, or a key in an attacker-controlled document) and rely on the signature being bound to the message: proof of possession, attribution, non-repudiation or deduplication. RFC 8032 doesn't require rejecting small-order public keys, and implementations differ. libsodium rejects them, and Node.js `crypto.verify()` (OpenSSL) rejects these signatures. The fix rejects a public key `A` when `[8]A` is the identity point. This covers all small-order points and their non-canon