Dev test stack: npm audit reports critical Vitest/Happy DOM advisories

[BorisTyshkevich]

Finding

A clean npm ci on main / the #365 branch reports 8 vulnerabilities: 3 critical, 2 high, and 3 moderate.

Direct dev dependencies involved:

• package.json:25 — @vitest/coverage-v8@^2.1.8 (critical via Vitest)
• package.json:29 — happy-dom@^15.11.0 (critical VM-context escape / module compiler advisories; audit fix is 20.x)
• package.json:31 — vitest@^2.1.8 (critical arbitrary-file read/execute advisory; audit fix is 4.x)

Transitive findings include Vite path traversal / Windows deny-bypass advisories, esbuild dev-server request exposure, and fast-uri host confusion.

Why deferred

This is unrelated to #365's saved-query persistence fixes. npm audit fix --force proposes coordinated semver-major upgrades (Vitest 4.x, Happy DOM 20.x), so it needs a focused compatibility change with the full 100% coverage gate and e2e verification rather than being folded into a bug-fix PR.

Repro

npm ci && npm audit

[BorisTyshkevich]

Triage (2026-07-22)

Confirmed on origin/main with npm audit --json: 8 findings (3 critical, 2 high, 3 moderate).

Disposition: security-relevant dev/CI maintenance; not a production-runtime incident. The application bundles no Vitest, Vite, or Happy DOM code, so the affected paths are local test execution and CI. It should nevertheless be prioritized as a focused upgrade because the critical Vitest advisory affects its UI server and the Happy DOM advisories include code-execution paths in the test environment.

This is not a lockfile-only fix:

• update vitest and @vitest/coverage-v8 together to the fixed 4.x release;
• update happy-dom to at least 20.11.0;
• regenerate package-lock.json, then resolve the resulting Vite/esbuild/fast-uri tree;
• run the full npm test coverage gate, npm run build, and the relevant Playwright suite.

Compatibility risk is established: PR #80 deliberately deferred the Vitest 4 major because it changed coverage measurement and failed the per-file gate even while tests passed. Preserve the current explicit thread-pool cap unless Vitest 4 requires an equivalent configuration, and treat any coverage/configuration adjustment as part of this issue's reviewed scope.

[BorisTyshkevich]

Implementation update (2026-07-22)

The compatible remediation is now prepared in local worktree triage/issue-366:

• vitest + @vitest/coverage-v8: ^2.1.8 → ^3.2.6 (resolved 3.2.7);
• happy-dom: ^15.11.0 → ^20.11.0;
• patched transitive lockfile graph, including fast-uri.

This is deliberately Vitest 3.2.x rather than 4.x. Vitest 4 runs the suite but its new V8 coverage remapping correctly changes the measured baseline enough to fail the repository's per-file coverage gate across many existing modules. Vitest 3.2.7 contains the security fix, resolves to an audit-clean graph, and preserves the tested coverage model.

Verification:

• npm audit --json — 0 vulnerabilities;
• npm test — 160 files / 4,679 tests, coverage gate passes;
• npm run build — passes;
• broad npm run test:e2e — one Chromium-only visual-test flake; the same test passed in Firefox and WebKit, and an immediate exact Chromium retry passed.

Also added a regression test for cross-document CodeMirror viewer adoption exposed by the Happy DOM upgrade, plus an Unreleased changelog entry.