Vitest: Servers misapply `server.fs.deny`, serving `.env`, private keys, `.git`, and the API token file

### Summary 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`. ### Details Vitest 5 adds its API token file to `server.fs.deny`, but neither server ended up with the intended list. That's because of two Vite behaviors. Vite applies its default deny list only when `server.fs.deny` is unset, and it compiles the list into a matcher during config resolution, so later changes to the array have no effect. | setup | listening server | Vite's default deny list | `.vitest-secret-token` | | ---------------------------------- | ------------------------------- | ------------------------ | ----------------------------------- | | plain `vitest` / `vitest run` | none | not reachable | not reachable | | `--ui` or `api` | root | denied | **served** (fallback location only) | | Browser Mode, single project | root (also the browser server) | denied | **served** (fallback location only) | | Browser Mode with `test.projects` | each browser project's server | **served** | denied | - **Project servers** set `deny: ['.vitest-secret-token']` from a `config()` hook, which replaces Vite's defaults. A project server listens on a port in Browser Mode with `test.projects`, so in that setup a request like `GET /.env?raw` returns the file. A plain `GET /.env` is also served as `text/javascript`, so a malicious page can include it with `<script src="http://localhost:<port>/.env">`. A classic script include needs no CORS, and each dotenv line whose value is valid JavaScript (a quoted string, number, or boolean) runs as a global assignment the page can read. A syntax error anywhere in the file, such as a `#` comment, keeps the whole script from running. The same missing defaults also loosen Browser Mode's file-access checks for `server.readFile`/`writeFile`/`removeFile`, screenshots, and traces. - **The root server** adds the token entry after Vite has compiled the matcher, so the entry is never applied. The token file normally lives in the per-user data directory, which is outside `server.fs.allow`. When that directory can't be written, for example in a container whose user has no writable `HOME`, Vitest falls back to `<workspaceRoot>/node_modules/.vitest/.vitest-secret-token`, which the root server then serves. The token authenticates the UI, `/__vitest_attachment__`, and the API WebSocket, whose RPC can write and rerun test files when `api.allowWrite`/`api.allowExec` are enabled. ### Impact Information disclosure from the Vitest dev server, and with the token, privileged API access. - **From a malicious website**, in Browser Mode with `test.projects`: while the browser server runs, any page the developer visits can read `.env` values that are valid JavaScript, through a classic `<script>` include. This works when the file consists of `KEY="value"` lines. An unquoted value causes a runtime error that stops the script at that line, so only the lines before it leak. A syntax error anywhere in the file, such as a `#` comment line or an `export` prefix, prevents the script from running at all. Recent Chrome versions may ask for Local Network Access permission first. `fetch` and XHR reads from other websites are still blocked by Vite's default CORS policy, and Vite's `Host` check blocks DNS rebinding. That CORS policy does allow localhost origins, so a page served from another local dev server could read full files. The token file can't be read through a classic `<script>`, because a bare token isn't valid JavaScript. - **With local access or developer-set network exposure** (such as `api.host` or `browser.api.host`, port forwarding, or a published container port): full file contents are readable over plain HTTP, including the token file when it's in the fallback location. Only the machine running Vitest is exposed, while it runs one of the setups above. Applications built or deployed from the project aren't affected. The fix is in `vitest` `<PATCHED>`. Vitest 4 and earlier are unaffected. They don't persist an API token, and they don't override `server.fs.deny`. ### Workaround Set `server.fs.deny` explicitly in the root Vitest config, including Vite's default list for your Vite version and the token file. For Vite 8.3: ```ts export default defineConfig({ server: { fs: { deny: [ '.env', '.env.*', '*.{crt,pem,key,p12,pfx,cer,der}', '.npmrc', '.yarnrc.yml', '**/.git/**', '.vitest-secret-token', ], }, }, }) ```

Source published

21 Oct 2026 19:57:00 UTC

Source modified

21 Oct 2026 20:01:39 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

Publisher rating · MODERATE