GHSA-848j-6mx2-7j84
Suggest an improvement- Source
- https://github.com/advisories/GHSA-848j-6mx2-7j84
- Import Source
- https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/01/GHSA-848j-6mx2-7j84/GHSA-848j-6mx2-7j84.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/GHSA-848j-6mx2-7j84
- Aliases
-
- CVE-2025-14505
- Related
- Published
- 2026-01-08T21:30:34Z
- Modified
- 2026-02-17T18:43:43.941806Z
- Severity
-
- 5.6 (Medium) CVSS_V3 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L CVSS Calculator
- 2.9 (Low) CVSS_V4 - CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P CVSS Calculator
- Summary
- Elliptic Uses a Cryptographic Primitive with a Risky Implementation
- Details
-
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).
- Database specific
{ "github_reviewed": true, "github_reviewed_at": "2026-01-09T20:19:43Z", "severity": "LOW", "nvd_published_at": "2026-01-08T21:15:42Z", "cwe_ids": [ "CWE-1240" ] }- References
Affected packages
npm / elliptic
Package
- Name
- elliptic
- View open source insights on deps.dev
- Purl
- pkg:npm/elliptic