Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-01T22:17:19.143Z",
  "pubdate": "2026-09-01T22:17:19.143Z",
  "executiveSummary": "A critical path traversal vulnerability exists in the Vitest testing framework due to improper validation of redirect targets within the mockerPlugin and interceptorPlugin.\nThe vulnerability allows unauthenticated remote attackers to bypass server file-system restrictions, specifically ignoring server.fs.allow and server.fs.deny configurations.\nBy submitting maliciously crafted payloads to the Vite HMR WebSocket, an attacker can coerce the development server into reading and disclosing arbitrary files from the host filesystem that the server process has permissions to access.\nThe issue affects Vitest versions from 2.1.0 up to, but not including, 4.1.11 and 5.0.0-rc.2.\nThis vulnerability poses a significant risk, as it permits unauthorized access to sensitive local files, source code, and configuration data, potentially leading to full compromise of the development environment.\nExploitation requires network connectivity to an exposed Vite development server, with no requirement for prior authentication on the default unauthenticated HMR WebSocket interface.",
  "technicalDetails": "The vulnerability resides within packages/mocker/src/node/interceptorPlugin.ts, where the vitest:interceptor:register handler fails to validate the event.redirect parameter against the server's established file-serving allowlist.\nThe root cause is a failure to invoke the isFileLoadingAllowed function when processing redirect requests. Consequently, the logic within the plugin resolves paths using join(server.config.root, redirectUrl.pathname) without checking if the resolved path is contained within the allowed project root or restricted directories.\nAn attacker can exploit this by sending a crafted request to the unauthenticated HMR WebSocket containing an opaque URL scheme or directory traversal sequences (e.g., '..'). Because the input is not sanitized or checked against Vite's filesystem security policies, the join operation resolves to arbitrary paths outside the intended project root.\nOnce a path is resolved to an attacker-controlled location, the plugin's load hook executes readFile(mock.redirect, 'utf-8'). This causes the contents of the target file to be returned as the module source, effectively leaking the file content to the remote client.\nWhile Vitest browser mode utilizes token-authenticated RPC, it shares the same missing boundary check as the HMR path, indicating a systemic flaw in the plugin's validation logic.\nThe attack flow proceeds as follows: 1) The attacker identifies a publicly accessible Vite development server. 2) The attacker connects to the HMR WebSocket and sends a registration message for a mock interceptor containing a malicious, path-traversal redirect URL. 3) The server processes the input, resolves the path to a sensitive file on the system (e.g., /etc/passwd or .env files), and ignores the server.fs.allow constraints. 4) The server reads the file and serves the content as a response, disclosing the sensitive data to the attacker.\nThe impact is complete directory traversal and local file inclusion (LFI) behavior, limited only by the filesystem permissions of the user running the Vitest development server process."
}