Vitest Dev
Monthly
Path traversal in Vitest Browser Mode (@vitest/browser) lets any client reachable via the Browser Mode API read, create, overwrite, or delete arbitrary files on the host running the test process, bypassing the allowWrite permission gate entirely. Affected are Vitest before 3.2.7, 4.x before 4.1.10, and the 5.0.0-beta line before 5.0.0-beta.6, where provider commands (upload, takeScreenshot, screenshotMatcher, stopChunkTrace, deleteTracing, annotateTraces) accept browser-supplied paths without confining them to the project root. There is no public exploit identified at time of analysis and it is not in CISA KEV; the highest-impact primitive is the upload command's arbitrary file read.
A path-traversal information disclosure in Vitest's mocker interceptor plugin requires a Windows host running the Vite dev server with WebSocket mock-registration enabled, and the attacker able to reach that server, to read files outside server.fs.allow that the Vitest process can access. The flaw arises because backslashes in a redirect mock pathname survive a POSIX-style join, so the allow-list check validates one path while the subsequent filesystem read resolves a different one - giving unauthenticated remote attackers read-only access to arbitrary process-readable files on Windows only. No public exploit code was identified at time of analysis and the flaw is not on the CISA KEV list; the high attack complexity and typical local binding of dev servers keep real-world risk moderate.
Vitest development servers running the @vitest/mocker interceptorPlugin can have attacker-controlled JavaScript injected into generated module source, which then executes on the development-server origin when a developer's browser loads the poisoned module. Affected versions are 2.1.0-beta.7 through 4.1.12-exclusive and up to 5.0.3-exclusive; the root cause is that createManualModuleSource interpolates an attacker-supplied mock url into generated code without escaping, so an unauthenticated non-browser WebSocket client that can reach the dev server can register a manual mock containing a breakout payload. Exploitation is constrained (CVSS 4.7, AC:H, UI:R, S:C, C:L/I:L/A:N) because a developer must subsequently load the affected module in a browser and because the surface is a development-time server rather than production; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Vitest dev servers in versions 5.0.0-beta.6 through 5.0.4 misapply Vite's server.fs.deny denylist, letting remote attackers who can reach a Vitest UI, Browser Mode, or API server read project files that should have been blocked and retrieve the fallback API token stored at node_modules/.vitest/.vitest-secret-token. A second variant, requiring Browser Mode with test.projects and a victim visiting an attacker-controlled site, leaks JavaScript-compatible .env values. No public exploit code or active exploitation has been identified at time of analysis, and the practical exposure is limited because these are development-only servers typically bound to localhost; the fix ships in Vitest 5.0.5.
Path traversal in Vitest's interceptorPlugin exposes local files on any development server with a network-accessible HMR WebSocket. The `vitest:interceptor:register` handler in `packages/mocker/src/node/interceptorPlugin.ts` accepts redirect mock registrations over Vite's unauthenticated HMR socket without calling `isFileLoadingAllowed()`, allowing a remote unauthenticated attacker who can reach the dev server to submit opaque-scheme URLs (e.g., `traversal:../../../etc/passwd`) whose `..` segments survive `URL.pathname` parsing and resolve outside the project root via `path.join()`. The plugin's `load` hook then returns `readFile(mock.redirect, 'utf-8')` as JavaScript module source, disclosing any file readable by the dev-server process. No public exploit or CISA KEV listing has been identified, but the GitHub fix PR includes a complete, working e2e test that serves as a functional PoC.
Vitest is a testing framework powered by Vite. Rated critical severity (CVSS 9.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Vitest is a testing framework powered by Vite. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. Epss exploitation probability 18.8%.
Path traversal in Vitest Browser Mode (@vitest/browser) lets any client reachable via the Browser Mode API read, create, overwrite, or delete arbitrary files on the host running the test process, bypassing the allowWrite permission gate entirely. Affected are Vitest before 3.2.7, 4.x before 4.1.10, and the 5.0.0-beta line before 5.0.0-beta.6, where provider commands (upload, takeScreenshot, screenshotMatcher, stopChunkTrace, deleteTracing, annotateTraces) accept browser-supplied paths without confining them to the project root. There is no public exploit identified at time of analysis and it is not in CISA KEV; the highest-impact primitive is the upload command's arbitrary file read.
A path-traversal information disclosure in Vitest's mocker interceptor plugin requires a Windows host running the Vite dev server with WebSocket mock-registration enabled, and the attacker able to reach that server, to read files outside server.fs.allow that the Vitest process can access. The flaw arises because backslashes in a redirect mock pathname survive a POSIX-style join, so the allow-list check validates one path while the subsequent filesystem read resolves a different one - giving unauthenticated remote attackers read-only access to arbitrary process-readable files on Windows only. No public exploit code was identified at time of analysis and the flaw is not on the CISA KEV list; the high attack complexity and typical local binding of dev servers keep real-world risk moderate.
Vitest development servers running the @vitest/mocker interceptorPlugin can have attacker-controlled JavaScript injected into generated module source, which then executes on the development-server origin when a developer's browser loads the poisoned module. Affected versions are 2.1.0-beta.7 through 4.1.12-exclusive and up to 5.0.3-exclusive; the root cause is that createManualModuleSource interpolates an attacker-supplied mock url into generated code without escaping, so an unauthenticated non-browser WebSocket client that can reach the dev server can register a manual mock containing a breakout payload. Exploitation is constrained (CVSS 4.7, AC:H, UI:R, S:C, C:L/I:L/A:N) because a developer must subsequently load the affected module in a browser and because the surface is a development-time server rather than production; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Vitest dev servers in versions 5.0.0-beta.6 through 5.0.4 misapply Vite's server.fs.deny denylist, letting remote attackers who can reach a Vitest UI, Browser Mode, or API server read project files that should have been blocked and retrieve the fallback API token stored at node_modules/.vitest/.vitest-secret-token. A second variant, requiring Browser Mode with test.projects and a victim visiting an attacker-controlled site, leaks JavaScript-compatible .env values. No public exploit code or active exploitation has been identified at time of analysis, and the practical exposure is limited because these are development-only servers typically bound to localhost; the fix ships in Vitest 5.0.5.
Path traversal in Vitest's interceptorPlugin exposes local files on any development server with a network-accessible HMR WebSocket. The `vitest:interceptor:register` handler in `packages/mocker/src/node/interceptorPlugin.ts` accepts redirect mock registrations over Vite's unauthenticated HMR socket without calling `isFileLoadingAllowed()`, allowing a remote unauthenticated attacker who can reach the dev server to submit opaque-scheme URLs (e.g., `traversal:../../../etc/passwd`) whose `..` segments survive `URL.pathname` parsing and resolve outside the project root via `path.join()`. The plugin's `load` hook then returns `readFile(mock.redirect, 'utf-8')` as JavaScript module source, disclosing any file readable by the dev-server process. No public exploit or CISA KEV listing has been identified, but the GitHub fix PR includes a complete, working e2e test that serves as a functional PoC.
Vitest is a testing framework powered by Vite. Rated critical severity (CVSS 9.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Vitest is a testing framework powered by Vite. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. Epss exploitation probability 18.8%.