Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions .nsprc
Original file line number Diff line number Diff line change
@@ -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"
}
}
2 changes: 1 addition & 1 deletion osv-scanner.toml
Original file line number Diff line number Diff line change
Expand Up @@ -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]]
Expand Down
Loading