Vitest vulnerabilities

Vitest from 5.0.0-beta.6 until 5.0.5 misapplies server.fs.deny because project servers replace Vite's defaults and the root server adds .vitest-secret-token after Vite compiles its matcher. An attacker who can reach an affected UI, Browser Mode, or API server can read denied project files or the fallback API token at node_modules/.vitest/.vitest-secret-token, and Browser Mode with test.projects can expose JavaScript-compatible .env values through a malicious website.

Vitest Browser Mode before versions 3.2.7, 4.1.10, and 5.0.0-beta.6 does not enforce the allowWrite permission gate or confine paths to the project root for commands such as upload, takeScreenshot, screenshotMatcher, stopChunkTrace, deleteTracing, and annotateTraces. A client that can reach the Browser Mode API can read arbitrary local files, create or overwrite image and trace files, or delete files accessible to the Vitest process even when allowWrite is false. This issue is fixed in versions 3.2.7, 4.1.10, and 5.0.0-beta.6.

A vulnerability in Vitest Browser Mode allows a remote attacker to bypass access controls and execute arbitrary Node.js code. The cdp() API forwards Chrome DevTools Protocol methods without checking allowWrite or allowExec permissions, enabling manipulation of the vite.config.ts file.

A vulnerability in the Vitest testing framework on Windows allows reading files outside the project via path traversal in /__vitest_attachment__ and arbitrary code execution through saveTestFile and rerun API functions. Fixed in versions 3.2.5 and 4.1.0.

A vulnerability in Vitest Browser Mode allows JavaScript injection via the otelCarrier query parameter in the /__vitest_test__/ path. An attacker can use a crafted URL to execute arbitrary code in the Vitest server origin and recover the VITEST_API_TOKEN for authenticated API calls.

From 4.1.11 until 4.1.12 and 5.0.3, isFileLoadingAllowed and the filesystem read interpret backslashes differently on Windows in packages/mocker/src/node/interceptorPlugin.ts in Vitest. When a client can reach the Vite dev server on Windows and register a redirect mock containing backslash traversal, POSIX joining preserves a Windows backslash traversal that the later filesystem read interprets as a path separator, so the client can read a file outside server.fs.allow that the Vitest process can access.

From 2.1.0-beta.7 until 4.1.12 and 5.0.3, an unauthenticated non-browser WebSocket client that can reach a development server using interceptorPlugin in Vitest can register a manual mock whose attacker-controlled url createManualModuleSource inserts unescaped into generated module source. When the developer browser loads the affected module, attacker-controlled JavaScript executes on the development-server origin.

Vitest is a testing framework powered by Vite. From 2.1.0 until 4.1.11 and 5.0.0-rc.2, the public mockerPlugin and standalone interceptorPlugin exports in packages/mocker/src/node/interceptorPlugin.ts register the vitest:interceptor:register handler on Vite's unauthenticated HMR WebSocket without validating redirect targets against the file-serving allowlist. The implementation processes event.redirect without enforcing server.fs.allow and server.fs.deny through isFileLoadingAllowed. A remote client that can reach an exposed development server can submit an opaque URL scheme preserving .. segments, causing join(server.config.root, redirectUrl.pathname) to resolve outside the project root. The plugin's load hook then returns readFile(mock.redirect, 'utf-8') as module source, disclosing local files readable by the dev-server process. Vitest browser mode uses a token-authenticated RPC and is not remotely unauthenticated by default, although the same boundary check was missing on that path. This issue is fixed in versions 4.1.11 and 5.0.0-rc.2.