REDHAT-BUG-2452457: High severity npm/node-forge vulnerability

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Published Mar 27, 2026

Updated

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

1 affected component

npm/node-forge<1.4.0

Event History

Mar 27, 2026

Data Sourced

via Red Hat·09:02 PM

DescriptionSeverityAffected Software

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.

REDHAT-BUG-2452457: High severity npm/node-forge vulnerability

Affected Software

Event History

Frequently Asked Questions

Which applications are most exposed to this issue?

What must an attacker have to exploit the vulnerability?

Are default node-forge signature-verification deployments affected?

What can be done if upgrading is not immediately possible?

Company

Resources

Contact

Frequently Asked Questions

Which applications are most exposed to this issue?

What must an attacker have to exploit the vulnerability?

Are default node-forge signature-verification deployments affected?

What can be done if upgrading is not immediately possible?