Summary
Move the server's transitive Vite dependency to Vite 8 to eliminate our exposure
to GHSA-gv7w-rqvm-qjhr
(esbuild Deno-module RCE, High / CVSS 8.1, fixed in esbuild 0.28.1).
Unlike the client, the server does not use Vite as a build tool — it builds
with tsc, dev-runs with tsx, and only pulls Vite in because Vitest embeds
it as its internal transform engine. That Vite chain currently drags in
esbuild@0.27.2. We are not exploitable (Node-only, dev-only, the vulnerable
Deno path is never invoked), so this is hygiene, not an emergency.
Root cause
The overrides block in package.json explicitly pins vite: "7.3.2", and
Vite 7 pins esbuild ^0.27.0. That pin is the only thing holding us on the
vulnerable esbuild line.
The fix (one line)
vitest@4.1.4 (already installed) supports Vite 8 — its peer range is
vite ^6.0.0 || ^7.0.0 || ^8.0.0 (^8 accepted since @vitest/mocker@4.1.0).
No Vitest upgrade is required.- Bump the existing override:
"overrides": {
"vite": "^8.0.0"
}(or drop the vite pin entirely and let Vitest resolve the highest
satisfying version, currently 8.0.16).
- Vite 8 carries no esbuild (it uses Rolldown + Lightning CSS), so esbuild
leaves the tree.
Scope of risk
Minimal. Vite here only powers Vitest's test transform/dev server — there is no
build pipeline, no shipped bundle, no vite.config, and no import 'vite' in
source. The only validation needed is that the test suite still passes on the
Vite 8 engine.
Compatibility notes
- Vite 8 requires Node
^20.19.0 || >=22.12.0; our engines is >= 22.
Confirm CI runners use >=22.12.
- Consider also bumping
vitest/@vitest/coverage-v8 from 4.1.4 to 4.1.9
(latest patch) opportunistically, but it is not required for Vite 8.
Acceptance criteria
Notes
- esbuild
0.28.1 was published 2026-06-11; per our supply-chain policy it is
still inside the 14-day quarantine. Since we are not exploitable, there is no
bypass justification — no rush to land before ~2026-06-25.
- Companion change: the client is a genuine Vite 7 → 8 bundler migration — see
the corresponding webssh2_client issue.
Summary
Move the server's transitive Vite dependency to Vite 8 to eliminate our exposure
to GHSA-gv7w-rqvm-qjhr
(esbuild Deno-module RCE, High / CVSS 8.1, fixed in esbuild 0.28.1).
Unlike the client, the server does not use Vite as a build tool — it builds
with
tsc, dev-runs withtsx, and only pulls Vite in because Vitest embedsit as its internal transform engine. That Vite chain currently drags in
esbuild@0.27.2. We are not exploitable (Node-only, dev-only, the vulnerableDeno path is never invoked), so this is hygiene, not an emergency.
Root cause
The
overridesblock inpackage.jsonexplicitly pinsvite: "7.3.2", andVite 7 pins
esbuild ^0.27.0. That pin is the only thing holding us on thevulnerable esbuild line.
The fix (one line)
vitest@4.1.4(already installed) supports Vite 8 — its peer range isvite ^6.0.0 || ^7.0.0 || ^8.0.0(^8accepted since@vitest/mocker@4.1.0).No Vitest upgrade is required.
(or drop the
vitepin entirely and let Vitest resolve the highestsatisfying version, currently
8.0.16).leaves the tree.
Scope of risk
Minimal. Vite here only powers Vitest's test transform/dev server — there is no
build pipeline, no shipped bundle, no
vite.config, and noimport 'vite'insource. The only validation needed is that the test suite still passes on the
Vite 8 engine.
Compatibility notes
^20.19.0 || >=22.12.0; ourenginesis>= 22.Confirm CI runners use
>=22.12.vitest/@vitest/coverage-v8from4.1.4to4.1.9(latest patch) opportunistically, but it is not required for Vite 8.
Acceptance criteria
overrides.vitebumped to^8(or removed); lockfile refreshed.esbuildno longer present in the tree (npm ls esbuildis empty).npm run test(build +vitest run) passes.npm run test:coveragepasses.npm auditno longer reports GHSA-gv7w-rqvm-qjhr.Notes
0.28.1was published 2026-06-11; per our supply-chain policy it isstill inside the 14-day quarantine. Since we are not exploitable, there is no
bypass justification — no rush to land before ~2026-06-25.
the corresponding webssh2_client issue.