Search for packages
| purl | pkg:npm/elliptic@6.5.4 |
| Next non-vulnerable version | None. |
| Latest non-vulnerable version | None. |
| Risk |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-2sfb-9txp-c7av
Aliases: CVE-2024-42459 GHSA-f7q4-pwc6-w24p |
Elliptic's EDDSA missing signature length check In the Elliptic package 6.5.6 for Node.js, EDDSA signature malleability occurs because there is a missing signature length check, and thus zero-valued bytes can be removed or appended. |
Affected by 3 other vulnerabilities. |
|
VCID-3rn2-srxp-p7bn
Aliases: CVE-2024-48949 GHSA-434g-2637-qmqr |
Elliptic's verify function omits uniqueness validation The Elliptic package 6.5.5 for Node.js for EDDSA implementation does not perform the required check if the signature proof(s) is within the bounds of the order n of the base point of the elliptic curve, leading to signature malleability. Namely, the `verify` function in `lib/elliptic/eddsa/index.js` omits `sig.S().gte(sig.eddsa.curve.n) || sig.S().isNeg()` validation. This vulnerability could have a security-relevant impact if an application relies on the uniqueness of a signature. |
Affected by 6 other vulnerabilities. |
|
VCID-ew32-3yaw-hfgg
Aliases: CVE-2025-14505 GHSA-848j-6mx2-7j84 |
Elliptic Uses a Cryptographic Primitive with a Risky Implementation The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which can lead to secret key exposure. This happens, because the byte-length of 'k' is incorrectly computed, resulting in its getting truncated during the computation. Legitimate transactions or communications will be broken as a result. Furthermore, due to the nature of the fault, attackers could–under certain conditions–derive the secret key, if they could get their hands on both a faulty signature generated by a vulnerable version of Elliptic and a correct signature for the same inputs. This issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1). | There are no reported fixed by versions. |
|
VCID-k6en-3w8h-sygy
Aliases: CVE-2024-42461 GHSA-49q7-c7j4-3p7m |
Elliptic allows BER-encoded signatures In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because BER-encoded signatures are allowed. |
Affected by 3 other vulnerabilities. |
|
VCID-naf1-wstu-budj
Aliases: GHSA-vjh7-7g9h-fjfh |
Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string) 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 |
Affected by 1 other vulnerability. |
|
VCID-p89g-d93c-ekfn
Aliases: CVE-2024-48948 GHSA-fc9h-whq2-v747 |
Valid ECDSA signatures erroneously rejected in Elliptic The Elliptic prior to 6.6.0 for Node.js, in its for ECDSA implementation, does not correctly verify valid signatures if the hash contains at least four leading 0 bytes and when the order of the elliptic curve's base point is smaller than the hash, because of an _truncateToN anomaly. This leads to valid signatures being rejected. Legitimate transactions or communications may be incorrectly flagged as invalid. |
Affected by 2 other vulnerabilities. |
|
VCID-t9fh-dydj-9bge
Aliases: CVE-2024-42460 GHSA-977x-g7h5-7qgw |
Elliptic's ECDSA missing check for whether leading bit of r and s is zero In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because there is a missing check for whether the leading bit of r and s is zero. |
Affected by 3 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-gzma-2y74-9ucn | Use of a Broken or Risky Cryptographic Algorithm The package elliptic is vulnerable to Cryptographic Issues via the secp256k1 implementation in `elliptic/ec/key.js`. There is no check to confirm that the public key point passed into the derive function actually exists on the secp256k1 curve. This results in the potential for the private key used in this implementation to be revealed after a number of ECDH operations are performed. |
CVE-2020-28498
GHSA-r9p9-mrjm-926w |