chore(deps): Resolve dependency vulnerabilities (2026-07-27)

.nsprc

@@ -15,8 +15,8 @@
         "notes": "@opentelemetry/core unbounded memory allocation in W3C Baggage propagation parsing (moderate). Reached only via @vscode/extension-telemetry@0.7.7 -> applicationinsights@2.5.0 -> @opentelemetry/core@1.10.1. Accepted risk: telemetry is permanently disabled in this extension (isTelemetryDisabled() in src/platform/telemetry/index.ts hard-returns true), so the Baggage propagator is never exercised. No safe transitive override exists: the fix is @opentelemetry/core>=2.8.0, but applicationinsights@2.5.0 and the 1.x @opentelemetry/sdk-trace-base and @opentelemetry/resources still in the tree call symbols removed in otel 2.x (getEnv, DEFAULT_ATTRIBUTE_COUNT_LIMIT, TracesSamplerValues), so forcing core to 2.x breaks them at runtime. The real remediation is upgrading @vscode/extension-telemetry to >=1.5.2 (which drops applicationinsights and @opentelemetry entirely) — a major upgrade deferred to a dedicated change.",
         "expiry": "2026-08-15"
     },
-    "GHSA-h67p-54hq-rp68": {
-        "notes": "js-yaml quadratic-complexity DoS in merge-key handling via repeated aliases (moderate). The top-level js-yaml dependency is bumped to the patched ^4.2.0 (an explicit `js-yaml@4` override is rejected by npm because js-yaml is also a direct dependency), which dedupes the other 4.x consumers. The remaining vulnerable copies are js-yaml@3.14.2, reached only through dev/test tooling (tslint -> js-yaml and @istanbuljs/load-nyc-config -> js-yaml, both declaring ^3.x). Accepted risk: no 3.x backport exists (latest 3.x is 3.14.2, still affected) and forcing these consumers to 4.x is a breaking API change (v4 removed safeLoad/safeDump). These paths run only during local lint/coverage, never in the shipped extension bundle, and do not parse untrusted YAML.",
+    "GHSA-mh99-v99m-4gvg": {
+        "notes": "CVE-2026-14257: brace-expansion DoS — expand() bounds the number of results (max, default 100000) but not the cumulative length of each result, so a small input built from repeated non-expanding groups exhausts the heap and crashes the process with an uncatchable OOM. The advisory range is <=5.0.7 with no lower bound, so it covers every published version except 5.0.8; the fix (EXPANSION_MAX_LENGTH, default 4000000 chars) exists only on the 5.x line and was never backported — 1.1.16 and 2.1.2 are the latest 1.x/2.x releases and both still cap only the result count. The 5.x copies (@vscode/vsce -> minimatch@10.2.5, vscode-extension-tester -> glob@13 -> minimatch@10.2.5) are pinned to the patched 5.0.8 via the `brace-expansion@>=5.0.0 <5.0.8` override, and the 1.x/2.x copies are pinned to 1.1.16/2.1.2 via the sibling overrides, which clears GHSA-3jxr-9vmj-r5cp on every line. Accepted risk: the residual copies are brace-expansion@1.1.16 and @2.1.2, held on their majors by minimatch@3.1.5 (^1.1.7), minimatch@5.1.9/8.0.7 (^2.0.1) and minimatch@9.0.9 (^2.0.2). Forcing them to 5.x is a breaking change, not just a semver violation: 1.x/2.x export a callable default (module.exports = expandTop) while 5.x exports only a named `expand`, so minimatch@3/5 (require('brace-expansion')(...)) and minimatch@8/9 (__importDefault(...).default(...)) throw at runtime — minimatch itself tried brace-expansion@^5 in 9.0.6-9.0.8 and reverted in 9.0.9. Reachability: glob patterns are never built from untrusted input — the shipped call site (FileSystem.globFiles in src/platform/common/platform/fileSystem.node.ts) passes extension-authored patterns, and the remaining paths (glob@9.3.5, vscode-languageclient, @deepnote/sql-language-server -> sqlite3/node-gyp and -> @google-cloud/bigquery -> rimraf) glob local build and workspace paths, not user-supplied brace expressions. The real remediation is upstream minimatch adopting brace-expansion 5.x.",
         "expiry": "2026-08-15"
     }
 }

build/esbuild/build.ts

@@ -81,6 +81,13 @@ const watchAll = process.argv.includes('--watch-all');
 const isWatchMode = watchAll || process.argv.includes('--watch');
 const extensionFolder = path.join(__dirname, '..', '..');
 
+// Package names whose root package.json `overrides` entry must be propagated into the generated
+// sql-lsp-modules package.json. That install runs in isolation with no lockfile and no inherited
+// overrides, so a transitive dependency pinned for security at the repo level would otherwise
+// resolve to a vulnerable version inside the shipped VSIX. Sourcing the pins from the root
+// package.json keeps them from drifting apart.
+const sqlLspOverridesToPropagate = ['ssh2', 'tar'];
+
 interface StylePluginOptions {
     /**
      * whether to minify the css code.
@@ -660,6 +667,20 @@ async function buildSqlLanguageServer() {
     await fs.ensureDir(sqlLspNodeModules);
 
     // Create a minimal package.json and install dependencies
+    const rootPackageJson = await fs.readJSON(path.join(extensionFolder, 'package.json'));
+    const rootOverrides: Record<string, string> = rootPackageJson.overrides || {};
+    const overrides: Record<string, string> = {};
+
+    for (const name of sqlLspOverridesToPropagate) {
+        if (typeof rootOverrides[name] === 'string') {
+            overrides[name] = rootOverrides[name];
+        } else {
+            throw new Error(
+                `Expected a string "${name}" entry in the root package.json overrides to propagate to sql-lsp-modules.`
+            );
+        }
+    }
+
     const packageJson = {
         name: 'sql-lsp-deps',
         version: '1.0.0',
@@ -669,7 +690,8 @@ async function buildSqlLanguageServer() {
             pg: '^8.9.0',
             sqlite3: '^5.0.3',
             '@google-cloud/bigquery': '^8.1.1'
-        }
+        },
+        overrides
     };
 
     const packageJsonPath = path.join(sqlLspNodeModules, 'package.json');