Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
@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: mock.redirect is derived from client input at registration time with no boundary check: There is no server.fs.allow / server.fs.deny check and no assertion that the…
Recommended action: Upgrade to 5.0.0-rc.2 (pre-release) or 4.1.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arbitrary file can be read on Windows when Vitest UI server is listening, especially when exposed to the network. Impact Only users that match either of the following conditions are affected: - explicitly exposes the Vitest UI server to the network (using --api.host or api.host config option) - running the Vitest UI or Browser Mode on Windows Details The API handler for /vitestattachment uses the deprecated isFileServingAllowed incorrectly. https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/ui/node/index.ts#L77 The function expects the passed value to use cleanUrl after the check before file system related operation. Because of this, it is possible to bypass the check by \\?\\..\\. This is not possible on Linux as Linux errors if a directory named ? does not exist. A similar problem exists in other places as well. -…
Recommended action: Upgrade to 4.1.0 or 3.2.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arbitrary remote Code Execution when accessing a malicious website while Vitest API server is listening by Cross-site WebSocket hijacking (CSWSH) attacks. Details When api option is enabled (Vitest UI enables it), Vitest starts a WebSocket server. This WebSocket server did not check Origin header and did not have any authorization mechanism and was vulnerable to CSWSH attacks. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L32-L46 This WebSocket server has saveTestFile API that can edit a test file and rerun API that can rerun the tests. An attacker can execute arbitrary code by injecting a code in a test file by the saveTestFile API and then running that file by calling the rerun API. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L66-L76 PoC 1. Open Vitest UI. 2. Access a malicious web site with the script below. 3. If you have calc…
Recommended action: Upgrade to 3.0.5, 2.1.9 or 1.6.1 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.