---
title: "GHSA-vjh7-7g9h-fjfh: Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string)"
url: https://erroneo.us/security/ghsa/GHSA-vjh7-7g9h-fjfh/
description: "GHSA-vjh7-7g9h-fjfh (critical, npm): Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string). Summary Private key can be…"
type: advisory
section: "Security Digest"
date_published: 2025-02-12
date_modified: 2025-02-23
publisher: erroneo.us
author: erroneo.us Security Desk
ghsa: "GHSA-vjh7-7g9h-fjfh"
license: All rights reserved. Quote with attribution and a link.
---

# GHSA-vjh7-7g9h-fjfh: Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string)

## Affected packages

- npm `elliptic` <= 6.6.0 → fixed: 6.6.1

## Details

Summary Private key can be extracted from ECDSA signature upon signing a malformed input (e.g. a string or a number), which could e.g. come from JSON network input Note that elliptic by design accepts hex strings as one of the possible input types Details In this code: https://github.com/indutny/elliptic/blob/3e46a48fdd2ef2f89593e5e058d85530578c9761/lib/elliptic/ec/index.js#L100-L107 msg is a BN instance after conversion, but nonce is an array, and different BN instances could generate equivalent arrays after conversion. Meaning that a same nonce could be generated for different messages used in signing process, leading to k reuse, leading to private key extraction from a pair of signatures Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still should not leak the private key Also, message validation could have the same bug (out of scope for this report, but could be possible in some situations), which makes this attack more likely when used in a chain PoC k reuse example Full attack This doesn't include code for generation/recovery on a purpose (bit it's rather trivial) Output: Similar for ed25519, but due to low n, the key might not match precisely but is nevertheless equivalent for signing: restored is equal to orig mod N. Impact Full private key extraction when signing a single malicious message (that passes JSON.stringify/JSON.parse)

## Sources

- [GitHub Advisory GHSA-vjh7-7g9h-fjfh](https://github.com/advisories/GHSA-vjh7-7g9h-fjfh)
- [github.com](https://github.com/indutny/elliptic/security/advisories/GHSA-vjh7-7g9h-fjfh)
- [github.com](https://github.com/indutny/elliptic/commit/04cb6f54ce552b3ebde6be06d6050419e1c7333e)

---
Source page: https://erroneo.us/security/ghsa/GHSA-vjh7-7g9h-fjfh/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt