REPRO-2026-00225: Verified Repro With Script Download

Node.js WebCrypto's EdDSA (Ed25519/Ed448) signature verification via globalThis.crypto.subtle.verify accepted signatures where the public key or the signature's R component is a small-order (low-order) point, before commit 29890721cda51eeb64f4079143d55b69333599c2. This allowed an attacker to forge signatures that verify as valid without knowing the private key, by exploiting the mathematical properties of small-order points in the Ed25519/Ed448 groups. The most severe variant uses the identity/neutral element (order-1 point), which satisfies the cofactorless verification equation for ANY message with S=0, enabling universal signature forgery.

• Package/component affected: Node.js built-in WebCrypto API (globalThis.crypto.subtle.verify for Ed25519 and Ed448), implemented in src/crypto/crypto_sig.cc
• Affected versions: Node.js builds prior to commit 29890721cda51eeb64f4079143d55b69333599c2 (dated 2026-06-20). The vulnerability existed in the v27.0.0-pre development branch and any release built from source before the fix was merged.
• Risk level: High. Any application using subtle.verify for Ed25519/Ed448 signature verification could accept forged signatures, enabling authentication bypass, authorization bypass, and integrity violation. An attacker who controls the public key (e.g., by submitting it during key exchange or registration) can produce valid-looking signatures for arbitrary messages without the private key.
• Consequences: Signature verification bypass — the core security property of EdDSA is defeated. Any system relying on WebCrypto Ed25519/Ed448 verification for authentication, authorization, or data integrity is vulnerable.

Impact Parity

• Disclosed/claimed maximum impact: Signature verification bypass (authz_bypass) — subtle.verify returns true for mathematically invalid signatures using small-order points.
• Reproduced impact from this run: Full verification bypass confirmed. The vulnerable Node.js build returns true for:
  • The ticket's specific order-8 point forgery (Test A)
  • The identity point (order-1) forgery for two different arbitrary messages (Tests B1, B2)
  • The fixed build returns false for all forged signatures, and both builds correctly reject a garbage signature (negative control, Test C).
• Parity: full
• Not demonstrated: No code execution, privilege escalation, or memory corruption — this is a pure logic/verification bypass vulnerability, consistent with the claimed impact.

Root Cause

Technical Explanation

Ed25519 signature verification checks the equation S*B = R + k*A where:

• S is the scalar from the signature (second 32 bytes)
• B is the base point (group generator)
• R is the point from the signature (first 32 bytes)
• A is the public key point
• k = SHA-512(R || A || M) mod l (where l is the prime group order ~2^252)

The Ed25519 group has cofactor 8, meaning the full group has order 8*l, with a small-order subgroup of order 8 (containing the identity, one order-2 point, two order-4 points, and four order-8 points). When the verification equation is checked without explicitly rejecting small-order points (cofactorless verification), certain special cases arise:

1. Identity point (order-1): When A = identity and R = identity with S = 0:

   • SB = 0B = O (identity)
   • k*A = k * identity = identity = O (identity has order 1, so any scalar multiple is identity)
   • R + k*A = identity + identity = identity = O
   • Therefore SB = O = R + kA → verification passes for ANY message

2. Order-8 point: When A and R are order-8 points with S = 0, and the message is chosen so that k*A = -R:

   • SB = O, R + kA = R + (-R) = O
   • Therefore SB = O = R + kA → verification passes

Before the fix, Node.js's crypto_sig.cc passed the public key and signature directly to OpenSSL's EVP_DigestVerifyFinal() for EdDSA verification. Depending on the OpenSSL variant, this cofactorless verification could accept these small-order point signatures. The Node.js code at line 757 (pre-fix) was simply:

if (context.verify(params.data, params.signature)) {
    static_cast<char*>(buf.get())[0] = 1;
}

No check was performed on whether the public key or R component was a small-order point.

Fix

The fix (commit 29890721cda51eeb64f4079143d55b69333599c2, PR #64026) adds a HasSmallOrderEdDsaPoint() function that checks both the signature's R component and the public key against hardcoded tables of all known small-order points for Ed25519 (14 points: 8 canonical + 6 non-canonical encodings) and Ed448 (4 points). The verification result is ANDed with this check:

if (context.verify(params.data, params.signature) &&
    !HasSmallOrderEdDsaPoint(key, params.signature)) {
    static_cast<char*>(buf.get())[0] = 1;
}

This ensures verification returns false whenever a small-order point is detected, regardless of OpenSSL's behavior.

• Fix commit: 29890721cda51eeb64f4079143d55b69333599c2
• PR: https://github.com/nodejs/node/pull/64026
• Issue: https://github.com/nodejs/node/issues/54572

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh
2. What the script does:
   • Locates the project cache (prepared with Node.js source and build infrastructure)
   • Uses two pre-built Node.js binaries from the same base commit (387332fbf3), differing ONLY in whether src/crypto/crypto_sig.cc contains the small-order point check from fix 29890721:
     • node-vuln-true: crypto_sig.cc reverted to fix parent (68f14c2ee6) — VULNERABLE
     • node-fixed-true: crypto_sig.cc with fix applied — FIXED
   • Runs a JavaScript test (ed25519_forgery_test.js) with each binary that:
     • Test A: Imports a small-order (order-8) Ed25519 public key and verifies a crafted signature with S=0 and small-order R, using the ticket's specific data
     • Test B: Imports the identity point (order-1) as both public key and R, with S=0, and verifies two different arbitrary messages
     • Test C: Negative control — verifies a garbage signature with a random public key (must fail on both builds)
   • Compares results: vulnerable build must accept forged signatures (true), fixed build must reject them (false), negative control must fail on both
   • Writes runtime manifest and proof logs
3. Expected evidence: Vulnerable build returns true for Tests A and B; fixed build returns false for all; both return false for Test C (negative control). Script exits 0.

Evidence

• Log files:
  • bundle/logs/vuln_test_output.log — raw JSON output from vulnerable binary: {"A_ticket":true,"B_identity_msg1":true,"B_identity_msg2":true,"C_negative_control":false}
  • bundle/logs/fixed_test_output.log — raw JSON output from fixed binary: {"A_ticket":false,"B_identity_msg1":false,"B_identity_msg2":false,"C_negative_control":false}
• Runtime manifest: bundle/repro/runtime_manifest.json
• Test script: bundle/repro/ed25519_forgery_test.js
• Key excerpts:
  • Vulnerable build: A_ticket: true (order-8 point forgery accepted), B_identity_msg1: true (identity point forgery accepted for message 1), B_identity_msg2: true (identity point forgery accepted for message 2)
  • Fixed build: All forged signatures rejected (false)
  • Negative control: Both builds correctly reject garbage signature (C_negative_control: false)
• Environment: Node.js v27.0.0-pre, built from source with bundled OpenSSL, x86_64 Linux, GCC. Both binaries built from the same base commit with identical compiler/toolchain, differing only in crypto_sig.cc (the fix).

Recommendations / Next Steps

• Upgrade guidance: Update to a Node.js version that includes commit 29890721cda51eeb64f4079143d55b69333599c2. Any application using WebCrypto Ed25519/Ed448 verification should ensure they are running a patched build.
• Suggested fix approach: The fix already implemented (explicit small-order point rejection in crypto_sig.cc) is the correct approach. It provides defense-in-depth by checking at the Node.js layer regardless of OpenSSL behavior.
• Testing recommendations: Add regression tests that verify all known small-order points for both Ed25519 and Ed448 are rejected during subtle.verify. The fix commit already adds these tests in test/parallel/test-webcrypto-sign-verify-eddsa.js.
• Additional hardening: Consider also rejecting small-order points during key import (subtle.importKey), though the fix intentionally keeps import behavior unchanged.

Additional Notes

• Idempotency: The reproduction script was run twice consecutively, both runs producing identical results and exiting with code 0.
• A/B comparison: Both binaries were built from the same base commit (387332fbf3) with identical compiler, toolchain, and build flags. The only difference is whether src/crypto/crypto_sig.cc contains the HasSmallOrderEdDsaPoint() function and its call-site check. This provides a clean negative control.
• Mathematical note on order-2/order-4 points: Tests with order-2 and order-4 points using S=0 do NOT automatically pass verification because R + k*A ≠ O unless k is specifically crafted to make k*A = -R. The identity point (order-1) is the strongest forgery primitive because k*identity = O for any k, making the forgery work for ANY message without any precomputation. The order-8 point from the ticket works because the specific data was chosen so that k*A = -R.
• Scope: This vulnerability affects the library_api surface (WebCrypto subtle.verify). The reproduction exercises the real Node.js binary executing the real globalThis.crypto.subtle.verify function with crafted inputs, not a mock or simulation.