GHSA-vjh7-7g9h-fjfh

What it actually does

The flaw affects the npm package elliptic and can allow ECDSA private key material to be recovered when a signing operation is performed over malformed input, such as a string value where the implementation expects properly formed message data. At a technical level, this is an information disclosure weakness in cryptographic signing: if an attacker can influence or supply malformed data that the application signs with an ECDSA private key through the vulnerable library version, the signing behavior may leak enough information to extract the private key. Compromise of that key can allow forged signatures, impersonation of the key holder, and bypass of systems that rely on the affected ECDSA key for authenticity or integrity.

Why it matters to the business

Applications using vulnerable versions of elliptic for ECDSA signing may expose cryptographic private keys if they sign attacker-controlled malformed input. The business risk depends on what the key protects: it may enable forged authentication tokens, fraudulent transactions, impersonation of services or users, tampering with signed messages, or compromise of software/package signing workflows. Because elliptic is a widely used JavaScript cryptography dependency that can be pulled in transitively by other packages, exposure may exist even where teams did not intentionally add it as a direct dependency. No public exploitation or KEV listing is indicated, but the impact of successful exploitation is high where signing endpoints or workflows accept untrusted input.

How an attack unfolds

An attacker first identifies an application or service that uses a vulnerable version of the elliptic npm package for ECDSA signing. The attacker then finds a path where they can cause the service to sign attacker-controlled data, such as an API endpoint, authentication challenge, blockchain or transaction workflow, message-signing feature, or token/signature generation routine. Instead of submitting well-formed message bytes, the attacker supplies malformed input, for example a string or other unexpected type. If the vulnerable signing path processes that input with an ECDSA private key, the resulting signature behavior can leak information correlated with the private key. By collecting one or more signatures generated from crafted malformed inputs, the attacker may derive the private key and then use it independently to create valid signatures without further access to the original service.

How to fix it

Upgrade elliptic to version 6.6.1 or later. For npm projects, update direct dependencies and regenerate lockfiles so the resolved version is fixed across all environments. If elliptic is present transitively, upgrade the parent dependency that brings it in, use package manager overrides/resolutions where appropriate, and verify the dependency tree resolves to elliptic 6.6.1 or newer. In addition, review all code paths that perform ECDSA signing and ensure signing functions accept only validated, normalized byte/message input, not arbitrary JavaScript types. If a vulnerable version may have signed attacker-controlled malformed input, treat affected ECDSA private keys as potentially compromised: rotate or revoke keys, invalidate derived credentials or tokens where feasible, and reissue trust material. Avoid relying solely on input validation as a long-term fix; the vulnerable library should be upgraded.

How to confirm the fix worked

Confirm that all deployed application builds, containers, serverless packages, and CI/CD artifacts resolve elliptic to 6.6.1 or later. Use package inventory and dependency tooling such as npm ls elliptic, npm audit, software composition analysis, lockfile inspection, and container image scanning. Verify that package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml no longer resolve elliptic to vulnerable versions. Review signing code to ensure untrusted inputs are normalized and type-checked before ECDSA signing. Where exposure is suspected, validate that keys used by vulnerable signing paths have been rotated and that old public keys, certificates, tokens, or trust anchors are no longer accepted. Functional testing should include attempts to submit malformed signing input and confirm it is rejected before reaching ECDSA signing routines.

Typical attack path

1. Identify a target application or library chain using a vulnerable version of the elliptic npm package before 6.6.1.
2. Locate functionality that performs ECDSA signing using elliptic and accepts attacker-influenced input.
3. Submit malformed signing input, such as string data or unexpected data types, rather than normalized byte/message input.
4. Collect signatures returned by the application from the malformed inputs.
5. Analyze the signature outputs to recover the ECDSA private key material.
6. Use the recovered private key to forge signatures, impersonate trusted parties, or bypass integrity/authenticity checks.

How to detect it

To assess prior exploitation, focus on applications that used elliptic before 6.6.1 and exposed ECDSA signing operations to users or external clients. Review API gateway, application, and service logs for requests to signing, token issuance, challenge-response, wallet, transaction, authentication, or message-signing endpoints that contain unexpected data types, stringified payloads, malformed JSON, unusually repeated signing attempts, or validation errors immediately followed by successful signature generation. Inspect application logs for TypeError, validation, serialization, or cryptographic signing anomalies involving malformed message input. If verbose/debug logs capture request bodies or signing inputs, search for cases where signing input was a JSON string rather than an expected byte array, hex string with strict format, Buffer, Uint8Array, or canonical message structure. Hunt for downstream abuse of recovered keys, including valid signatures from unusual clients, token issuance outside expected workflows, signed transactions inconsistent with normal user behavior, or use of old keys after rotation. There are no universal network IOCs because exploitation is application-specific and may look like legitimate signing requests; detection is strongest where signing endpoint telemetry, request schemas, and key-use audit logs are available.

• elliptic@6.6.0
• elliptic@6.5.7
• elliptic@6.5.6
• node_modules/elliptic/package.json
• package-lock.json: elliptic
• yarn.lock: elliptic
• pnpm-lock.yaml: elliptic
• npm ls elliptic
• TypeError
• ECDSA
• sign(
• signing malformed input
• malformed input
• unexpected string
• invalid message type
• signature generated

What your security team should do

• Inventory all JavaScript and Node.js applications, build artifacts, and container images for the elliptic npm package, including transitive dependency paths.
• Prioritize upgrade of elliptic to 6.6.1 or later in services that perform ECDSA signing, issue signed tokens, process financial or blockchain transactions, sign software artifacts, or expose signing functions to users or external systems.
• Regenerate and redeploy lockfiles and production artifacts to ensure runtime environments are not still using a cached vulnerable dependency.
• Review application routes and APIs for signing operations that accept user-controlled input, and enforce strict input type validation and canonicalization before signing.
• Rotate ECDSA private keys if vulnerable signing paths were reachable by untrusted users or logs show malformed signing requests during the exposure window.
• Add tests to prevent regression by asserting that signing functions reject strings or unexpected object types when byte/message input is required.
• Monitor dependency advisories and SCA results for transitive reintroduction of vulnerable elliptic versions.