CVE-2026-33895

What it actually does

The flaw is an Ed25519 signature verification weakness in Forge/node-forge before version 1.4.0. The verifier incorrectly accepts non-canonical Ed25519 signatures where the scalar component S is greater than or equal to the Ed25519 group order L. As a result, an attacker who has one valid signature can create a different byte sequence, such as an S + L variant, that still verifies in affected Forge versions even though standards-compliant implementations such as OpenSSL-backed Node.js crypto.verify reject it. This does not let an attacker sign arbitrary new content without a valid signature, but it can break assumptions that signatures are unique or canonical, enabling bypasses in systems that use signature bytes for replay prevention, authorization decisions, deduplication, signed-object identity, or cross-library consistency checks.

Why it matters to the business

Applications that rely on Forge/node-forge for Ed25519 verification may accept altered signatures as valid, which can allow attackers to bypass replay controls, duplicate transaction protections, approval workflows, or authorization checks. The operational risk is highest for systems where signed messages, tokens, documents, API requests, blockchain-like records, software update metadata, or identity assertions are treated as unique based on the signature bytes. Although this vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known mature public exploit reported in the provided data, the issue is security-significant because similar Ed25519 malleability bugs have been exploited in practice.

How an attack unfolds

An attacker first obtains or observes a legitimate Ed25519-signed object that is accepted by an application using a vulnerable version of Forge/node-forge. Instead of forging a signature for new content, the attacker modifies the signature encoding so that the S scalar is represented in a non-canonical form, such as adding the group order L to the original S value while keeping the signature associated with the same message. A standards-compliant verifier rejects the modified signature, but vulnerable Forge versions accept it. If the application tracks replay, uniqueness, authorization state, or object identity by the raw signature bytes, the modified signature can appear to be a new signed object while still validating cryptographically in the vulnerable application. This may allow replay of previously authorized actions, duplicate submission of signed transactions, bypass of deduplication, or inconsistencies between services that use different Ed25519 verification libraries.

How to fix it

Upgrade Forge/node-forge to version 1.4.0 or later wherever Ed25519 signature verification may be used. Because Forge is commonly introduced as a transitive JavaScript dependency, review package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container images, bundled frontend/backend artifacts, and vendored JavaScript dependencies for affected versions. Rebuild and redeploy applications after dependency updates rather than only updating source manifests. If immediate upgrade is not possible, mitigate by rejecting non-canonical Ed25519 signatures before verification, validating signatures with a standards-compliant implementation such as Node.js crypto/OpenSSL, and avoiding business logic that relies on raw signature byte uniqueness. Prefer canonical signed-object identifiers derived from the message or a domain-separated digest rather than from the signature bytes alone.

How to confirm the fix worked

Confirm that all deployed JavaScript applications and packaged artifacts use Forge/node-forge version 1.4.0 or later. Use dependency tooling such as npm ls node-forge, yarn why node-forge, pnpm why node-forge, npm audit, SCA scanners, and lockfile searches to verify that no vulnerable version remains. Add a regression test using a known valid Ed25519 signature and a non-canonical S + L variant: the valid signature should verify and the non-canonical variant must be rejected. Where multiple services verify the same signatures, test that Forge-based verification behavior matches standards-compliant Node.js crypto/OpenSSL verification. Also validate application-level replay and deduplication controls by ensuring that modified signature encodings cannot create a second accepted submission for the same signed message.

Typical attack path

1. Identify an application endpoint or workflow that accepts Ed25519-signed messages, tokens, requests, records, or artifacts.
2. Confirm or infer that the verifier is implemented with Forge/node-forge before version 1.4.0.
3. Capture or obtain a legitimate signed object for a message the attacker is allowed to see or submit.
4. Create a non-canonical variant of the existing Ed25519 signature by altering the S scalar so that it is not reduced modulo the group order.
5. Submit the modified signature with the original signed message to the vulnerable application.
6. Rely on the affected verifier accepting the non-canonical signature as valid.
7. Abuse application logic that treats the modified signature as distinct, such as replay tracking, deduplication, authorization state, or signed-object canonicalization.

How to detect it

This vulnerability does not produce a universal network signature, process artifact, or file indicator because exploitation consists of submitting cryptographically malformed but otherwise normal-looking signed data to application-specific workflows. To investigate possible prior exploitation, review application logs, API gateway logs, transaction records, audit trails, and message-processing logs for cases where the same signed payload, request body, transaction content, token claims, or object digest was accepted more than once with different Ed25519 signature byte values. Compare any suspicious accepted signatures against a standards-compliant verifier such as Node.js crypto.verify/OpenSSL; signatures accepted by Forge but rejected by OpenSSL are strong evidence of attempted exploitation or probing. Pay particular attention to replay-prevention failures, duplicate submissions, repeated approvals, repeated withdrawals or transfers, duplicated signed documents, duplicate update metadata, or authorization events where the payload is identical but the signature differs. If logs store only signature hashes, look for multiple successful records with identical message hashes but different signature hashes. Where feasible, instrument verification code temporarily to log rejected non-canonical Ed25519 signatures and accepted signatures whose S component is greater than or equal to the group order.

What your security team should do

• Prioritize inventory of all direct and transitive uses of Forge/node-forge, especially in authentication, authorization, signed API request, transaction, token, document-signing, and update-verification paths.
• Upgrade affected deployments to node-forge 1.4.0 or later and rebuild all dependent services, containers, serverless packages, and bundled artifacts.
• Add negative security tests for non-canonical Ed25519 signatures to CI/CD pipelines and cryptographic validation test suites.
• Review application logic that uses raw signature bytes for replay prevention, deduplication, object identity, or authorization state, and replace it with canonical message digests or server-side nonce/state controls.
• Search recent logs and transaction records for repeated signed messages accepted with different signature byte strings, especially where the same payload produced multiple successful actions.
• If affected workflows protect high-value operations, perform targeted forensic review for duplicate or replayed signed requests since the vulnerability publication date.
• Standardize Ed25519 verification behavior across services to avoid split-brain acceptance where one component accepts signatures that another rejects.