CVE-2026-84373

## Summary `@vitest/mocker` registers a redirect mock's target path without validating it against the dev server's file-serving allowlist. An attacker who can reach the dev server's WebSocket can register a redirect mock pointing outside the project root; when the mocked module is requested, the plugin's `load` hook returns `readFile(<attacker path>)` as the module source, disclosing local files. This is exploitable **without authentication** only through the public `mockerPlugin` / standalone `interceptorPlugin` exports (used by third-party dev servers), which register the handler on Vite's unauthenticated HMR socket. Vitest's own browser mode registers mocks over a **token-authenticated** RPC and is not remotely reachable by default (see Scope). ## Affected code `packages/mocker/src/node/interceptorPlugin.ts`. The `load` hook is the file-read sink: ```ts if (mock.type === 'redirect') { return readFile(mock.redirect, 'utf-8') } ``` `mock.redirect` is derived from client input at registration time with no boundary check: ```ts if (event.type === 'redirect') { const redirectUrl = new URL(event.redirect) event.redirect = join(server.config.root, redirectUrl.pathname) } registry.register(event) ``` There is no `server.fs.allow` / `server.fs.deny` check and no assertion that the resolved path stays within the project root. ## Registration paths and trust boundaries - **Public `mockerPlugin` / `interceptorPlugin` (unauthenticated).** In `configureServer`, the plugin registers `server.ws.on('vitest:interceptor:register', …)` on Vite's HMR WebSocket. That socket performs no token, Origin, or same-origin check, so any client that can reach it can register a redirect mock. This is the path the "unauthenticated" impact applies to. - **Vitest browser mode (authenticated).** Mocks register over the browser RPC (`registerMock`), which sits behind a per-run token (`isValidApiRequest`, a random `api.token`). The interceptor's `configureServer` socket is n