REDHAT-BUG-2452457: High severity npm/node-forge vulnerability
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (S >= 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. This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see CVE-2026-25793, CVE-2022-35961). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed. Version 1.4.0 patches the issue.
Affected Software
Event History
Frequently Asked Questions
Which applications are most exposed to this issue?
Applications that use node-forge to verify Ed25519 signatures and rely on each valid signature having a unique byte representation are exposed. This includes designs that deduplicate by signature bytes, track replays by signature value, or enforce signed-object canonicalization checks.
What must an attacker have to exploit the vulnerability?
An attacker needs a valid Ed25519 signature. They can create an alternate non-canonical signature by using an S value of S + L, which node-forge versions before 1.4.0 accepts even though the specification requires rejection.
Are default node-forge signature-verification deployments affected?
Any use of affected node-forge versions to verify Ed25519 signatures can accept the malformed S + L variant. The practical security impact depends on whether the application treats signature byte values as unique for authentication, authorization, replay prevention, or canonicalization.
What can be done if upgrading is not immediately possible?
Reject Ed25519 signatures whose scalar S is not reduced modulo the group order, and avoid using raw signature bytes as the sole replay, deduplication, or canonicalization identifier. Using a verifier that rejects the non-canonical S + L form, such as the described Node.js crypto.verify behavior, can also prevent acceptance of this variant.