From a6b8330a0a3aa55ddadba4e3615dc4a9fc8e12f2 Mon Sep 17 00:00:00 2001 From: tomas Date: Sat, 17 Oct 2026 08:44:39 +0000 Subject: [PATCH] chore(deps): extend elliptic audit exception to 2026-11-06 and correct advisory notes `Audit - All` (better-npm-audit) and `Qlty Check` (osv-scanner) fail on main because the accepted-risk entry for elliptic (GHSA-848j-6mx2-7j84, low) expired on 2026-10-17. No new advisory has been published: npm audit, osv-scanner 2.3.0/2.7.0, an OSV batch query of every locked package and the GitHub Advisory DB agree on the same three advisories for the root lockfile and none for the perf fixture lockfile. elliptic: renewed rather than remediated (ladder rung 5, as in #531). elliptic 6.6.1 (2024-11-13) is still the latest release, the advisory lists no patched version, and the upstream fix PRs (#345, #351, #354) are unmerged. The expiry moves to 2026-11-06 in both .nsprc and osv-scanner.toml, matching braces and sprintf-js (as #327 aligned all exceptions), so one renewal covers all three. The note is corrected: - the nonce k is truncated, producing an incorrect signature; only ECDSA signing with an EC key is affected; - out/extension.web.bundle.js does bundle elliptic (node:crypto -> crypto-browserify), but nothing calls createSign/createVerify/ createECDH; - "native browser crypto" is not a remediation, since @deepnote/convert needs a synchronous createHash; the verified alternative (empty-pkg override plus a web-test-only stub alias) is recorded instead. braces and sprintf-js: exceptions and expiries unchanged; stale or wrong claims in their notes are corrected: - both: "npm audit reports fixAvailable:false" was wrong; npm suggests semver-major downgrades (gulp@3.9.1 / @vscode/vsce@4.0.0, nyc@14.1.1) that leave the vulnerable package installed; - braces: mocha no longer reaches braces since #289 (mocha 11.8 uses chokidar 4); gulp's findup-sync chain and chokidar's ~3.0.2 range are recorded; the maintainer disputes the report (micromatch/braces#70); - sprintf-js: CVE-2026-97058 was rejected by its CNA on 2026-10-12 (NVD: Rejected), but the GHSA is not withdrawn yet. Verified locally: `better-npm-audit audit` exits 1 on main (advisory 1112030) and 0 with this change; `--production` exits 0 on both. osv-scanner 2.3.0 with the repo config exits 1 on main (elliptic 6.6.1) and 0 with this change; the perf fixture lockfile scans clean. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01NMBxX24nF2qRaSRtmgH9mB --- .nsprc | 8 ++++---- osv-scanner.toml | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/.nsprc b/.nsprc index 5af7bce6c..0e752d574 100644 --- a/.nsprc +++ b/.nsprc @@ -1,14 +1,14 @@ { "GHSA-848j-6mx2-7j84": { - "notes": "CVE-2025-14505: elliptic's ECDSA signing mis-computes the byte length of the nonce k when k has leading zeros, emitting a truncated signature; an attacker who obtains both a faulty and a correct signature over the same input can recover the private key. Accepted risk: dev-only transitive dependency, absent from the production tree (`npm ls elliptic --omit=dev` is empty). Reached only via node-stdlib-browser@1.3.1 -> crypto-browserify@3.12.1 -> browserify-sign@4.2.5 / create-ecdh@4.0.4 -> elliptic@6.6.1. node-stdlib-browser is a devDependency used exclusively by build/esbuild/build.ts, whose stdlib polyfill plugin is applied only to the web test entry (src/test/web/index.ts -> out/extension.web.bundle.js, excluded from the VSIX by `out/**` in .vscodeignore); the production desktop and web bundles never pull it in, confirmed by the absence of node_modules/elliptic, node_modules/browserify-sign and node_modules/crypto-browserify inputs in dist/*.esbuild.meta.json. No code in this extension performs ECDSA signing. No patched upstream release is currently available: every published elliptic release is affected (range <=6.6.1, and 6.6.1 is the latest version on npm, published 2024-11-13), GitHub lists no patched version, and npm audit reports fixAvailable:false. The real remediation is an upstream elliptic release, or dropping node-stdlib-browser from the web test bundle in favour of native browser crypto.", - "expiry": "2026-10-17" + "notes": "CVE-2025-14505: elliptic's ECDSA signing mis-computes the byte length of the nonce k when k has leading zeros and truncates it, emitting an incorrect signature; an attacker who obtains both a faulty and a correct signature over the same input can, under certain conditions, recover the private key. Only ECDSA signing (crypto-browserify's createSign with an EC key) is affected. Accepted risk: dev-only transitive dependency, absent from the production tree (`npm ls elliptic --omit=dev` is empty). Reached only via node-stdlib-browser@1.3.1 -> crypto-browserify@3.12.1 -> browserify-sign@4.2.5 / create-ecdh@4.0.4 -> elliptic@6.6.1. node-stdlib-browser is a devDependency used exclusively by build/esbuild/build.ts, whose stdlib polyfill plugin is applied only to the web test entry (src/test/web/index.ts -> out/extension.web.bundle.js, excluded from the VSIX by `out/**` in .vscodeignore). That bundle does include elliptic, because the plugin resolves node:crypto to crypto-browserify both for @deepnote/convert's static import of createHash and randomUUID, which loads it at startup, and for the Node-only dynamic import in src/platform/common/crypto.ts. The production desktop and web bundles never pull it in, confirmed by the absence of node_modules/elliptic, node_modules/browserify-sign and node_modules/crypto-browserify inputs in dist/*.esbuild.meta.json. No code in this extension or in @deepnote/convert calls createSign, createVerify or createECDH. No patched upstream release is currently available: every published elliptic release is affected (range <=6.6.1, and 6.6.1 is the latest version on npm, published 2024-11-13), GitHub lists no patched version, npm audit reports fixAvailable:false, and the upstream fix PRs (indutny/elliptic#345, #351, #354) are unmerged. Native browser crypto cannot replace the polyfill, because @deepnote/convert needs a synchronous createHash. Alternative remediation if no upstream fix lands: a root `elliptic` override to npm:empty-pkg@1.0.0 plus an alias of elliptic to a `module.exports = {}` stub in the web test build only (browserify-sign and create-ecdh require('elliptic') and empty-pkg ships no entry point, so the override alone fails that build with `Could not resolve \"elliptic\"`). That replaces elliptic@6.6.1 in the lockfile with empty-pkg, removes it from the bundle, and leaves only createECDH and EC-key createSign/createVerify non-functional in the web test polyfill.", + "expiry": "2026-11-06" }, "GHSA-vfj7-8cjw-p6xm": { - "notes": "CVE-2026-93687: braces has no recursion-depth guard in its parse/compile/expand walkers, so a deeply nested brace pattern exhausts the call stack and throws an uncaught RangeError (denial of service). Accepted risk: not shipped and not reachable with untrusted input. One copy, braces@3.0.3 (held by the root `braces` override), pulled in by micromatch@4.0.8 and chokidar@3.5.3. npm counts it as production only because @jupyterlab/filebrowser lists jest-environment-jsdom under `dependencies` (jest-environment-jsdom -> @jest/fake-timers -> jest-message-util -> micromatch), which never runs at runtime. No dist/**/*.esbuild.meta.json has node_modules/braces or node_modules/micromatch inputs, dist/sqlLanguageServer.cjs bundles neither, dist/sql-lsp-modules does not install them, and node_modules/** is excluded from the VSIX by .vscodeignore. The dev-time callers (mocha and gulp via chokidar; esbuild-plugin-import-glob and @vscode/vsce via fast-glob) expand only glob patterns written in this repository. No patched upstream release is currently available: every published braces release is affected (range <=3.0.3, and 3.0.3 is the latest version on npm, published 2024-05-21), GitHub lists no patched version, npm audit reports fixAvailable:false, and micromatch@4.0.8 and fast-glob@3.3.3 (both latest) require braces ^3.0.3. When a patched braces is published, raise or delete the exact `braces` override (it would otherwise hold the tree on 3.0.3) and remove this entry.", + "notes": "CVE-2026-93687: braces has no recursion-depth guard in its parse/compile/expand walkers, so a deeply nested brace pattern exhausts the call stack and throws an uncaught RangeError (denial of service). Accepted risk: not shipped and not reachable with untrusted input. One copy, braces@3.0.3 (held by the root `braces` override), pulled in by micromatch@4.0.8 and chokidar@3.5.3. npm counts it as production only because @jupyterlab/filebrowser lists jest-environment-jsdom under `dependencies` (jest-environment-jsdom -> @jest/fake-timers -> jest-message-util -> micromatch), which never runs at runtime. No dist/**/*.esbuild.meta.json has node_modules/braces or node_modules/micromatch inputs, dist/sqlLanguageServer.cjs bundles neither, dist/sql-lsp-modules does not install them, and node_modules/** is excluded from the VSIX by .vscodeignore. The dev-time callers (gulp via glob-watcher -> chokidar and gulp-cli -> liftoff -> findup-sync -> micromatch; esbuild-plugin-import-glob and @vscode/vsce via fast-glob) expand only glob patterns written in this repository or hard-coded in those tools. No patched upstream release is currently available: every published braces release is affected (range <=3.0.3, and 3.0.3 is the latest version on npm, published 2024-05-21), GitHub lists no patched version, and the maintainer disputes the report (micromatch/braces#70). npm audit's fixAvailable for braces is a semver-major change that leaves braces installed (a downgrade to gulp@3.9.1, or @vscode/vsce@4.0.0 on some runs). micromatch@4.0.8 (latest, also required by fast-glob@3.3.3, latest) requires braces ^3.0.3, and chokidar@3.5.3 requires ~3.0.2. When a patched braces is published, raise or delete the exact `braces` override (it would otherwise hold the tree on 3.0.3) and remove this entry and its osv-scanner.toml mirror.", "expiry": "2026-11-06" }, "GHSA-hp3w-g68c-fv3c": { - "notes": "CVE-2026-97058: sprintf-js passes unbounded precision specifiers (e.g. `%.999f`) straight to Number#toFixed/toExponential/toPrecision, which throw an uncaught RangeError, so an attacker who controls a format string can abort the calling operation. Accepted risk: not shipped and not reachable. One copy, sprintf-js@1.0.3, reached only via @istanbuljs/load-nyc-config@1.1.0 -> js-yaml@3.15.2 (held by the `js-yaml@3` override) -> argparse@1.0.10 -> sprintf-js. It is dev-only, absent from the production tree (`npm ls sprintf-js --omit=dev` is empty), and reached only through the devDependency nyc@15.1.0. load-nyc-config calls only js-yaml load(); js-yaml 3 requires argparse solely from its bin/js-yaml.js CLI, which nothing here invokes; and argparse formats only its own usage/help templates with sprintf. No dist/**/*.esbuild.meta.json has node_modules/sprintf-js or node_modules/argparse inputs, dist/sqlLanguageServer.cjs bundles neither, dist/sql-lsp-modules does not install them, and node_modules/** is excluded from the VSIX. No patched upstream release is currently available: every published sprintf-js release is affected (range <=1.1.3, and 1.1.3 is the latest version on npm, published 2023-09-11), GitHub lists no patched version, and npm audit reports fixAvailable:false. argparse@1 pins sprintf-js ~1.0.2, so a future 1.1.x fix would still need an override; the alternative remediation is overriding `argparse@1` to 2.0.1, whose CommonJS API js-yaml 3 load() never touches.", + "notes": "CVE-2026-97058: sprintf-js passes unbounded precision specifiers (e.g. `%.999f`) straight to Number#toFixed/toExponential/toPrecision, which throw an uncaught RangeError, so an attacker who controls a format string can abort the calling operation. Accepted risk: not shipped and not reachable. One copy, sprintf-js@1.0.3, reached only via @istanbuljs/load-nyc-config@1.1.0 -> js-yaml@3.15.2 (held by the `js-yaml@3` override) -> argparse@1.0.10 -> sprintf-js. It is dev-only, absent from the production tree (`npm ls sprintf-js --omit=dev` is empty), and reached only through the devDependency nyc@15.1.0. load-nyc-config calls only js-yaml load(); js-yaml 3 requires argparse solely from its bin/js-yaml.js CLI, which nothing here invokes; and argparse formats only its caller's usage/help templates and one fixed error message (`ignored explicit argument %r`) with sprintf. No dist/**/*.esbuild.meta.json has node_modules/sprintf-js or node_modules/argparse inputs, dist/sqlLanguageServer.cjs bundles neither, dist/sql-lsp-modules does not install them, and node_modules/** is excluded from the VSIX. No patched upstream release is currently available: every published sprintf-js release is affected (range <=1.1.3, and 1.1.3 is the latest version on npm, published 2023-09-11), and GitHub lists no patched version. npm audit's fixAvailable is a semver-major downgrade to nyc@14.1.1, which still depends on js-yaml ^3.13.1 and so on sprintf-js; the latest nyc (18.0.0) still requires @istanbuljs/load-nyc-config ^1.0.0, whose latest release (1.1.0) requires js-yaml ^3.13.1. CVE-2026-97058 was rejected by its CNA (VulnCheck) on 2026-10-12 and NVD lists it as Rejected, but GHSA-hp3w-g68c-fv3c is not withdrawn; once it is, delete this entry and its osv-scanner.toml mirror. argparse@1 pins sprintf-js ~1.0.2, so a future 1.1.x fix would still need an override; the alternative remediation is overriding `argparse@1` to 2.0.1, whose CommonJS API js-yaml 3 load() never touches.", "expiry": "2026-11-06" } } diff --git a/osv-scanner.toml b/osv-scanner.toml index 072aa9b63..4e49f1962 100644 --- a/osv-scanner.toml +++ b/osv-scanner.toml @@ -3,7 +3,7 @@ [[IgnoredVulns]] id = "GHSA-848j-6mx2-7j84" -ignoreUntil = 2026-10-17 +ignoreUntil = 2026-11-06 reason = "CVE-2025-14505 (elliptic): dev-only, via node-stdlib-browser; no patched release. See .nsprc." [[IgnoredVulns]]