CVE-2026-33895
Ed25519 Signature Malleability in Forge Allows Authentication Bypass
Publication date: 2026-03-27
Last updated on: 2026-04-14
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| digitalbazaar | forge | to 1.3.3 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-347 | The product does not verify, or incorrectly verifies, the cryptographic signature for data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability CVE-2026-33895 is a signature forgery issue in the Ed25519 implementation within the node-forge cryptographic library. The core problem is that the signature verification process accepts non-canonical signatures where the scalar component S of the signature is not reduced modulo the group order L, meaning S can be greater than or equal to L. According to the Ed25519 specification, the scalar S must be strictly less than L to be considered valid.
Because of this missing check, both a valid signature and a forged variant with S + L (mod 2^256) are accepted as valid by node-forge, whereas other implementations like Node.js's crypto.verify (OpenSSL-backed) correctly reject the forged variant. This flaw allows attackers to create forged signatures that bypass authentication and authorization mechanisms relying on signature uniqueness.
How can this vulnerability impact me? :
This vulnerability enables signature malleability, allowing attackers to forge signatures that bypass security controls relying on the uniqueness of signatures. Applications that depend on deduplication by signature bytes, replay protection, or signed-object canonicalization checks can be circumvented.
- Bypassing authentication and authorization logic.
- Circumventing replay tracking mechanisms.
- Evading signature uniqueness checks, potentially allowing unauthorized actions.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by verifying whether Ed25519 signatures accepted by your system or application enforce the canonical scalar check, ensuring the scalar component S of the signature is strictly less than the group order L. A practical detection method involves testing signature verification with both a valid signature and a forged signature where the scalar S is increased by L (S + L). If both signatures verify successfully, the system is vulnerable.
A proof-of-concept (PoC) script exists that generates a valid Ed25519 signature and then creates a forged signature by adding the group order L to the scalar S component. This script verifies both signatures using the vulnerable forge library and a secure Node.js crypto module (OpenSSL-backed). The vulnerable system accepts both, while the secure one rejects the forged signature.
To detect the vulnerability on your system, you can run a similar test using Node.js with the following conceptual commands:
- Generate an Ed25519 keypair and sign a test message using your current node-forge version.
- Modify the signature by adding the Ed25519 group order L to the scalar S portion of the signature.
- Attempt to verify both the original and modified signatures using your system's verification function.
- If both signatures verify successfully, your system is vulnerable.
Note: The exact commands depend on your environment, but the PoC script referenced in the advisory can be adapted for this purpose.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the node-forge library to version 1.4.0 or later, where the vulnerability is patched by adding a canonical scalar check during Ed25519 signature verification.
This patch introduces a function that verifies the scalar S component of the signature is strictly less than the Ed25519 group order L, rejecting any non-canonical signatures (where S ≥ L) and preventing signature malleability.
If upgrading immediately is not possible, consider implementing a custom verification step that rejects signatures with non-canonical scalars, or switch to a cryptographic library that correctly enforces the Ed25519 specification (such as Node.js's crypto module backed by OpenSSL).
Additionally, review your application's authentication and authorization logic to ensure it does not rely solely on signature uniqueness without proper canonical checks.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in the forge Ed25519 implementation allows signature malleability, meaning forged non-canonical signatures can bypass authentication and authorization mechanisms that rely on signature uniqueness.
This can undermine security controls such as deduplication by signature bytes, replay protection, and signed-object canonicalization checks.
Since authentication and authorization are critical for protecting sensitive data, this vulnerability could lead to unauthorized access or actions, potentially violating compliance requirements in standards like GDPR and HIPAA that mandate strong access controls and data integrity.
Therefore, applications using the affected forge versions without the fix may face increased risk of non-compliance due to weakened cryptographic assurances.