Mocker
Monthly
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.
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.
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.
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.