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
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In Vitest 5, Vite's server.fs.deny is not applied as intended on Vitest's dev servers. Depending on the server, files that Vite refuses to serve by default (such as .env, private keys and certificates, .npmrc, and .git) or Vitest's own API token file (.vitest-secret-token) can be read over plain HTTP by a client that can reach the server. In Browser Mode with test.projects, a malicious website can also read .env values through the developer's browser. This only applies when Vitest runs an HTTP server, which happens with the UI (--ui), Browser Mode, or api enabled. Plain vitest and vitest run don't listen on any port and are not affected. The fix ships in vitest, and @vitest/ui and @vitest/browser are listed because they are what enables the affected setups. Both pin vitest to the same version as a peer dependency, so upgrading either one also requires the patched vitest. Users who enable api without @vitest/ui or @vitest/browser are also affected and should upgrade vitest.…
Recommended action: Upgrade to 5.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Browser Mode exposes a set of built-in "commands" that run on the Node.js side of the test runner and can touch the local filesystem (taking screenshots, managing Playwright traces, uploading files for <input type="file", comparing screenshots). Several of these commands accept a file path from the browser and act on it without checking the allowWrite permission gate and without confining the path to the project directory. A client that can reach the Browser Mode API can therefore read, create, overwrite, or delete files anywhere the Vitest process can access, even when allowWrite is false. This matters most when the Browser Mode API is exposed to the network (for example test.api.host is set, or the dev server is reachable from another machine or origin). In that configuration allowWrite defaults to false precisely to block file access, and these commands bypass that protection. On a default localhost-only setup with trusted test code, there is no untrusted party in a…
Recommended action: Upgrade to 5.0.0-beta.6 (pre-release), 4.1.10 or 3.2.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vitest Browser Mode exposes a cdp() API that forwards raw Chrome DevTools Protocol (CDP) methods over the Vitest browser WebSocket RPC. CDP is not gated by browser.api.allowWrite, browser.api.allowExec, api.allowWrite, or api.allowExec. As a result, disabling Browser Mode write and exec operations does not prevent a browser API client from using CDP to perform equivalent actions. In a verified reproduction with allowWrite: false and allowExec: false, CDP Page.setDownloadBehavior set the browser download directory to the project root, and CDP Runtime.evaluate downloaded a controlled vite.config.ts. Vitest reloaded the changed config and executed attacker-controlled Node.js code. When the Browser Mode API is also exposed to the network, this becomes remotely exploitable because the generated browser runner page exposes the API token, active session id, project name, and project root path needed to connect to the browser WebSocket API and select the target download directory.…
Recommended action: Upgrade to 5.0.0-beta.4 (pre-release), 4.1.8 or 3.2.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vitest browser mode served /vitesttest/ with the otelCarrier query parameter inserted directly into an inline module script. Because this value was treated as JavaScript source rather than data, an attacker could craft a browser-runner URL that executes arbitrary JavaScript in the Vitest server origin. https://github.com/vitest-dev/vitest/blob/cba2036a197ec8ed42c35a37db78ef07192202c7/packages/browser/src/node/serverOrchestrator.ts#L48 https://github.com/vitest-dev/vitest/blob/cba2036a197ec8ed42c35a37db78ef07192202c7/packages/browser/src/client/public/esm-client-injector.js#L41 The same generated page embeds VITESTAPITOKEN, which is used to authenticate Vitest WebSocket APIs. Script execution in this origin can therefore recover the token and make authenticated API calls. Impact This issue affects users running Vitest browser mode. A victim must open or navigate to a crafted Vitest browser-runner URL while the Vitest browser server is running. In the default local browser-mode…
Recommended action: Upgrade to 5.0.0-beta.3 (pre-release) or 4.1.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
screenshot-error handler on the browser mode HTTP server that responds any file on the file system. Especially if the server is exposed on the network by browser.api.host: true, an attacker can send a request to that handler from remote to get the content of arbitrary files. Details This screenshot-error handler on the browser mode HTTP server responds any file on the file system. https://github.com/vitest-dev/vitest/blob/f17918a79969d27a415f70431e08a9445b051e45/packages/browser/src/node/plugin.ts#L88-L130 This code was added by https://github.com/vitest-dev/vitest/commit/2d62051f13b4b0939b2f7e94e88006d830dc4d1f. PoC 1. Create a directory and change the current directory to that directory 1. Run npx vitest init browser 1. Run npm run test:browser 2. Run curl http://localhost:63315/screenshot-error?file=/path/to/any/file Impact Users explicitly exposing the browser mode server to the network by browser.api.host: true may get any files exposed.
Recommended action: Upgrade to 3.0.4 or 2.1.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.