CVE-2024-48949

What it actually does

The flaw is in the EdDSA signature verification logic of the Node.js elliptic package before 6.5.6. The verifier fails to reject signatures whose S component is negative or greater than or equal to the curve order. Because EdDSA scalar operations are normally reduced modulo the curve order, a non-canonical signature can be accepted even though it violates the required encoding rules. The most likely technical impact is signature malleability: an attacker who has a valid signature may be able to produce alternate encodings of that signature that still verify. In systems that rely on exact signature bytes for uniqueness, replay prevention, transaction identifiers, authorization tokens, or audit integrity, this can undermine those controls. This is not generally equivalent to recovering private keys or forging arbitrary signatures without first having a valid signature/message pair.

Why it matters to the business

Applications that use vulnerable versions of elliptic for EdDSA verification may accept malformed but valid-looking signatures. This can create operational risk where signatures are used for payments, signed messages, software update metadata, API authentication, blockchain-style transaction identity, non-repudiation, or deduplication. The current public exploitation signal is low: it is not in the CISA Known Exploited Vulnerabilities catalog, is not known to be used in ransomware campaigns, has low EPSS, and no exploit maturity is reported. However, because cryptographic libraries are often embedded transitively in many JavaScript applications, exposure may be hidden inside dependencies and should be remediated through dependency updates rather than dismissed.

How an attack unfolds

An attacker first identifies an application or protocol path that verifies EdDSA signatures using a vulnerable version of the elliptic package. The attacker obtains or observes a legitimate signed message, token, request, transaction, or artifact. Instead of creating a new signature from the private key, the attacker alters the S component of the existing signature into a non-canonical value, such as by adding the curve order, while preserving a value that reduces to the same scalar during verification. Because the vulnerable verifier does not enforce that S is non-negative and less than the curve order, the modified signature may still be accepted. The attacker then submits the altered signed object to bypass controls that assume a signature has one canonical byte representation, such as duplicate detection, replay prevention, transaction-hash calculation, signature allowlists, or audit correlation.

How to fix it

Upgrade the elliptic package to a fixed release. The vulnerability is fixed in elliptic 6.5.6 and in the upstream Git repository at commit 7ac5360118f74eb02da73bdf9f24fd0c72ff5281. For npm-based projects, update direct and transitive dependencies, regenerate lockfiles, and rebuild/redeploy affected applications. Where exact dependency control is required, pin elliptic to a fixed version or use package manager overrides/resolutions to force all transitive consumers to use the fixed release. If immediate upgrade is not possible, add compensating validation before calling the vulnerable verifier or at the signature ingestion boundary: reject EdDSA signatures whose S component is negative, not canonically encoded, or greater than or equal to the curve order. Also avoid relying on raw signature bytes as unique identifiers; derive identity from canonicalized message content and strict verification results.

How to confirm the fix worked

Confirm all deployed dependency trees use elliptic 6.5.6 or later, or contain the upstream fix commit 7ac5360118f74eb02da73bdf9f24fd0c72ff5281 if using a Git-sourced package. Run package inventory commands such as npm ls elliptic, yarn why elliptic, pnpm why elliptic, and software composition analysis tooling against source repositories, build artifacts, and container images. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and bundled node_modules directories for elliptic versions older than 6.5.6. As a functional validation, add a negative test using an EdDSA signature with a non-canonical S value that previously verified; the fixed implementation should reject it. Verify production builds are rebuilt after dependency updates rather than only updating source manifests.

Typical attack path

1. Find an application, service, API, wallet, protocol implementation, or verification workflow that uses elliptic EdDSA verification from a vulnerable package version.
2. Obtain a legitimate message and its corresponding EdDSA signature, for example through normal user access, public transaction data, logs, intercepted traffic, or a previously issued token.
3. Parse the signature and modify the S component into a non-canonical value that should be rejected by a strict EdDSA implementation.
4. Submit the altered signed object to the target verifier.
5. Rely on the vulnerable verifier accepting the malformed signature as valid.
6. Abuse any downstream logic that treats the altered signature bytes as a distinct object, transaction, token, or authorization event.

How to detect it

There are no universal host, process, file, registry, or network indicators that prove exploitation because the issue is a cryptographic validation weakness inside application logic. Detection requires application-specific review of signed objects and verification workflows. Search application, API gateway, authentication, transaction, and message-processing logs for repeated submissions of the same message, request body, token payload, transaction payload, or artifact hash with different EdDSA signature byte strings. Where raw signatures are logged or retained, decode EdDSA signatures and flag any with an S component that is negative, non-canonically encoded, or greater than or equal to the curve order. Compare acceptance behavior between the vulnerable verifier and a strict EdDSA implementation; any historical object accepted only by the vulnerable implementation should be investigated. For exposed services, look for bursts of signature verification failures followed by successful submissions of semantically identical messages, which may indicate probing. In forensic analysis, identify vulnerable deployments by searching dependency manifests and deployed artifacts for elliptic versions before 6.5.6, then correlate their runtime logs with duplicate-message/different-signature patterns.

What your security team should do

• Inventory all JavaScript and Node.js applications, libraries, serverless functions, containers, and build artifacts for elliptic versions before 6.5.6, including transitive dependencies.
• Prioritize remediation for systems that verify EdDSA signatures for authentication, authorization, financial transactions, signed messages, software updates, blockchain or ledger workflows, or replay prevention.
• Upgrade elliptic to 6.5.6 or later, or ensure the upstream fix commit 7ac5360118f74eb02da73bdf9f24fd0c72ff5281 is present in Git-based dependencies.
• Use package manager overrides or resolutions to eliminate vulnerable transitive copies and verify lockfiles are updated.
• Add regression tests that reject non-canonical EdDSA signatures, especially S values greater than or equal to the curve order.
• Review application logic that uses signature bytes as identifiers, cache keys, transaction IDs, or deduplication keys; migrate to canonical representations where needed.
• Monitor for unusual repeated submissions of the same logical message with different signature byte strings, even though broad exploitation is not currently reported.