CVE-2024-42459

What it actually does

CVE-2024-42459 is a cryptographic weakness in the Node.js elliptic package version 6.5.6 affecting EDDSA signature handling. The implementation does not strictly enforce the expected signature length, allowing zero-valued bytes to be removed from or appended to a signature while still having it accepted as valid. This creates signature malleability: multiple byte-level encodings can represent a signature that verifies successfully. The primary impact is weakened signature canonicalization and potential bypass of systems that rely on exact signature bytes for uniqueness, replay prevention, deduplication, audit integrity, or token/message binding. The CVSS impact is limited, with low confidentiality impact and no direct integrity or availability impact assigned, but application-specific consequences can be more serious where signature byte equality is security-critical.

Why it matters to the business

Applications that use the vulnerable elliptic EDDSA implementation may accept altered versions of otherwise valid signatures, which can undermine trust controls built around digital signatures. Business consequences may include unreliable audit trails, incorrect duplicate detection, weakened anti-replay controls, inconsistencies between services that canonicalize signatures differently, and possible exposure of signed data workflows to abuse. The vulnerability is not listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, so broad active exploitation is not currently indicated; however, the package is commonly used in JavaScript ecosystems, so indirect exposure through dependencies should be assessed.

How an attack unfolds

An attacker first identifies an application or service that uses elliptic 6.5.6 for EDDSA signature verification and obtains or observes a legitimate signed message/signature pair. Because the vulnerable verifier does not require the EDDSA signature to be exactly the expected length, the attacker modifies the signature encoding by removing or appending zero-valued bytes. The altered signature may still verify as valid even though its raw byte representation differs from the original. The attacker then submits the modified signature to application logic that treats the changed byte sequence as a distinct signature, object, request, transaction, or proof. Exploitation is most relevant where the application relies on the raw signature value as a unique identifier, cache key, replay-prevention value, authorization artifact, or audit reference rather than validating both the cryptographic result and canonical encoding.

How to fix it

Upgrade the elliptic package to a version that includes strict EDDSA signature length validation when an upstream fixed release is available. Because no fixed version was provided in the input, confirm the current patched version from the official npm package advisory, GitHub repository, or package lockfile metadata before deploying. Remove or override transitive dependency pins that force elliptic 6.5.6. If immediate upgrade is not possible, add application-level validation that rejects EDDSA signatures whose decoded/raw length does not exactly match the expected length for the curve in use, and normalize signature handling so security decisions do not rely solely on raw signature byte equality. Rebuild and redeploy affected Node.js services after dependency updates, and regenerate lockfiles to ensure vulnerable versions are not retained.

How to confirm the fix worked

Confirm exposure by inspecting package manifests and lockfiles for elliptic version 6.5.6, including transitive dependencies in package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml. Use dependency scanners such as npm audit, osv-scanner, Snyk, GitHub Dependabot, or equivalent software composition analysis tools to verify the vulnerable version is absent. Validate the fix with a unit or integration test that submits a valid EDDSA signature, then submits variants with appended zero bytes and removed zero bytes; the patched or mitigated application should reject all non-canonical-length signatures. Confirm deployed artifacts, containers, and serverless bundles contain the upgraded dependency and were rebuilt after lockfile changes.

Typical attack path

1. Identify a Node.js application, API, library, wallet, signing workflow, or authentication component that depends on elliptic 6.5.6 for EDDSA verification.
2. Obtain a valid EDDSA-signed message and its corresponding signature through normal access, observation, logs, client-side traffic, or public signed data.
3. Create alternate encodings of the valid signature by appending zero-valued bytes or removing zero-valued bytes where accepted by the vulnerable implementation.
4. Submit the modified signature with the original message to a verification endpoint or signed-data workflow.
5. Rely on the vulnerable verification behavior to accept the modified signature as valid.
6. Abuse downstream application logic that treats the modified signature bytes as a new or different artifact, potentially bypassing deduplication, replay checks, audit correlation, or signature uniqueness assumptions.

How to detect it

This vulnerability does not have a universal network exploit pattern or product-specific log signature because exploitation depends on how an application uses EDDSA signatures. To investigate possible prior exploitation, review application logs for repeated submissions of the same signed message or transaction with different signature byte strings, especially where signatures differ only by leading, trailing, appended, or removed 00 bytes. Examine API gateway, authentication, webhook, transaction, and audit logs for duplicate message identifiers, payload hashes, nonces, or timestamps associated with multiple distinct signatures that all verified successfully. In forensic review, compare accepted EDDSA signatures against the expected fixed length for the curve and flag any accepted signature whose raw or decoded length is shorter or longer than expected. Also search source, dependency, and deployment artifacts for elliptic 6.5.6 to identify services that could have accepted malleated signatures during the exposure window.

• elliptic@6.5.6
• node_modules/elliptic/package.json
• "elliptic": "6.5.6"
• "elliptic":"6.5.6"
• "version": "6.5.6"
• package-lock.json
• npm-shrinkwrap.json
• yarn.lock
• pnpm-lock.yaml

What your security team should do

• Inventory all applications, services, build artifacts, and containers using the Node.js elliptic package, including transitive dependencies.
• Prioritize remediation for systems using EDDSA signatures in authentication, authorization, transaction signing, replay prevention, signed webhooks, cryptographic proofs, or audit-critical workflows.
• Upgrade elliptic from version 6.5.6 to a patched version once verified from the upstream advisory, and ensure lockfiles and transitive dependency overrides do not preserve the vulnerable release.
• Add regression tests that verify malformed EDDSA signatures with appended or removed zero bytes are rejected.
• Review application logic for unsafe reliance on raw signature bytes as unique identifiers, replay-prevention tokens, or audit correlation keys.
• Enable software composition analysis in CI/CD to detect reintroduction of vulnerable elliptic versions.
• Because this issue is not currently KEV-listed and has low EPSS, treat it as normal-priority for most environments, but elevate priority where digital signatures directly protect financial, identity, authorization, or non-repudiation workflows.