CVE-2026-47429 - Vitest UI API file read and RCE

Vitest versions before 4.1.0 exposed dangerous file and execution primitives when the Vitest UI/API server was listening. On Windows, path-cleaning mistakes allowed file-serving checks to be bypassed. More importantly, when the API or UI is exposed to the network, authenticated Vitest API features such as file write and test rerun can amount to script execution in the project workspace.

The practical risk is highest for Windows developers, remote dev environments, shared workstations, forwarded devcontainer ports, and CI jobs that start Vitest UI or browser mode with sensitive environment variables. The correct fix is to upgrade and make test-server exposure policy explicit, not merely avoid a single file-serving endpoint.

When to use it

Use this recipe when a repository runs Vitest UI or its API server in local development, shared workstations, devcontainers, Codespaces, preview environments, or CI where the server might be reachable by untrusted users. It is designed for source-code/config remediation, test-runner file boundary review, credential hygiene, and evidence that UI/API routes cannot read files or trigger execution outside intended local workflows.

Inputs

  • Vitest version, package manager and lockfile state, UI/API config, test scripts, devcontainer/CI commands, container images, and generated dependency reports.
  • Source/config paths that enable vitest --ui, set host/API bindings, expose ports, mount workspaces/secrets, or configure privileged test runner actions.
  • Regression fixtures or safe checks for fixed versions, loopback binding, disabled exposed privileged operations, denied file reads, and safe CI/dev defaults.
  • Boundary evidence: workspace files, repository/package/cloud/model-provider credentials, forwarded ports, shared runner ownership, logs, and rollout owner.

Affected versions

  • Vulnerable package: vitest <4.1.0
  • Fixed package: vitest 4.1.0+
  • Affected surfaces: Vitest UI/API server, __vitest_attachment__, browser mode file operations, file write, and rerun-capable API paths
  • High-risk runtime: Windows, or any network-reachable Vitest UI/API server

Indicator-of-exposure

  • The repository depends on vitest <4.1.0.
  • Scripts, docs, devcontainers, CI jobs, or task runners start Vitest UI with --ui, vitest --ui, browser mode, watch mode, API server config, or non-loopback host bindings.
  • Vitest UI/API binds to 0.0.0.0, a LAN address, a devcontainer forwarded port, Codespaces, a tunnel, preview environment, or shared remote workstation.
  • Developers or CI runners use Windows while the Vitest UI/API server is listening.
  • The test runner environment can read source checkouts, .env files, package-manager credentials, cloud credentials, browser artifacts, SSH keys, model-provider keys, or release tokens.

Quick checks:

rg -n "\"vitest\"|vitest --ui|--ui|@vitest/ui|__vitest_attachment__|saveTestFile|rerun|allowWrite|allowExec|api\\.host|--host|0\\.0\\.0\\.0|browser:\\s*\\{" .
npm ls vitest @vitest/ui @vitest/browser
pnpm why vitest @vitest/ui @vitest/browser
yarn why vitest @vitest/ui @vitest/browser

Windows:

rg -n "\"vitest\"|vitest --ui|--ui|@vitest/ui|__vitest_attachment__|saveTestFile|rerun|allowWrite|allowExec|api\\.host|--host|0\\.0\\.0\\.0|browser:\\s*\\{" .
npm ls vitest @vitest/ui @vitest/browser
pnpm why vitest @vitest/ui @vitest/browser
yarn why vitest @vitest/ui @vitest/browser

Do not retrieve the Vitest API token, request __vitest_attachment__ with crafted paths, use saveTestFile, invoke rerun through the API, or test with real secret-bearing workspaces.

Remediation strategy

  • Upgrade every controlled vitest dependency, lockfile, workspace, devcontainer, CI image, package cache, generated dependency report, and SBOM to 4.1.0+.
  • Keep @vitest/ui, @vitest/browser, Vite, and related test packages compatible with the fixed Vitest release.
  • Bind Vitest UI/API to loopback by default. Remove accidental non-loopback bindings from scripts, docs, devcontainers, and CI jobs.
  • For any approved network-reachable Vitest server, disable privileged operations with the fixed-version controls such as allowWrite and allowExec, and document the owner of the exception.
  • Avoid running Vitest UI/API in secret-bearing CI or release jobs. Split interactive test servers from package publishing, deployment, and release verification environments.
  • If affected UI/API servers were exposed, review logs and rotate long-lived tokens that were present in the runner environment.

The prompt

You are remediating CVE-2026-47429 / GHSA-5xrq-8626-4rwp, a Vitest UI/API
server issue that can allow file reads and, when privileged API operations are
reachable, project-file writes or script execution. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Vitest, hardens UI/API host
  exposure and privileged operation policy, adds safe regression checks,
  refreshes generated artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not use an affected Vitest UI/API or
  browser-mode runtime.

## Rules

- Scope only CVE-2026-47429 / GHSA-5xrq-8626-4rwp and directly related Vitest
  UI/API exposure.
- Treat Vitest API tokens, environment variables, `.env` files, source files,
  package tokens, repository tokens, cloud credentials, model-provider keys,
  SSH keys, generated artifacts, and test logs as sensitive.
- Do not fetch API tokens, request crafted attachment paths, call
  `saveTestFile`, trigger rerun through the API, write config/test files
  through Vitest, or execute proof-of-concept chains.
- Do not remove tests, UI workflows, browser-mode coverage, or CI gates just to
  silence the advisory.
- Do not auto-merge.

## Steps

1. Inventory every `vitest`, `@vitest/ui`, `@vitest/browser`, Vite test
   workspace, lockfile, Dockerfile, devcontainer, CI image, package-manager
   cache, generated dependency report, SBOM, and test script controlled by this
   repository.
2. Determine every resolved `vitest` version. A target is vulnerable if it
   resolves below `4.1.0`.
3. Search for UI/API and browser-mode launch paths:
   `vitest --ui`, `--ui`, `api.host`, `--host`, `0.0.0.0`, forwarded ports,
   devcontainer or Codespaces port publishing, tunnels, preview links,
   browser-mode config, watch-mode scripts, `allowWrite`, and `allowExec`.
4. Classify each Vitest server:
   local loopback-only, Windows local developer, trusted CI without inbound
   access, remote dev workspace, shared workstation, preview environment,
   tunneled server, or internet/network-exposed server.
5. If the repository does not use Vitest UI/API or browser mode, stop with
   `TRIAGE.md` listing checked files and the external owner if a platform image
   supplies Vitest.
6. Upgrade all controlled Vitest package references to `vitest 4.1.0+`.
   Refresh package locks, generated dependency reports, SBOMs, devcontainer
   images, CI caches, and docs that pin or install Vitest.
7. Harden UI/API exposure:
   - bind to loopback by default;
   - remove accidental `0.0.0.0`, forwarded port, and tunnel defaults;
   - require an explicit reviewed exception for non-loopback UI/API servers;
   - disable `allowWrite` and `allowExec` for network-reachable servers;
   - document any remaining interactive network exposure and owner.
8. Reduce runner authority:
   - keep Vitest UI/API out of release, deploy, and package-publish jobs;
   - remove long-lived package, cloud, model-provider, and repository tokens
     from UI/API jobs;
   - use isolated workspaces for remote interactive test servers;
   - avoid mounting host secrets into devcontainers that expose Vitest ports.
9. Add safe regression checks that do not exploit the issue:
   - resolved Vitest version is `4.1.0+`;
   - scripts/config do not expose UI/API on non-loopback hosts without an
     allow-listed exception;
   - any network-exposed exception disables write and execute capabilities;
   - Windows developer docs do not recommend exposed UI/API servers;
   - logs and validation output omit tokens, environment values, and file
     contents.
10. Add a PR body section named `CVE-2026-47429 operator actions` that states:
    - Vitest versions before and after;
    - where UI/API or browser mode runs;
    - whether Windows or network-exposed servers were in scope;
    - which write/execute operations remain enabled, if any;
    - which long-lived tokens or secrets may have been present and whether
      rotation is required;
    - which validation commands passed.
11. Run available validation: package install, lockfile integrity, unit tests,
    UI/browser tests without exploit input, lint/typecheck, CI config lint,
    dependency/security scans, SBOM refresh, and devcontainer or image checks.
12. Use PR title:
    `fix(sec): remediate CVE-2026-47429 in Vitest UI`.

## Stop conditions

- No affected Vitest UI/API, browser-mode runtime, package pin, image, or
  workspace is controlled by this repository.
- A fixed Vitest version cannot be consumed without a broader test framework
  migration.
- The only affected Vitest runtime is supplied by another platform owner; name
  the owner, required version, and exposure assumptions in `TRIAGE.md`.
- Verification would require reading tokens, requesting crafted file paths,
  writing files through Vitest, triggering reruns through the API, or exposing
  live secrets.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Vitest, refreshes lockfiles/generated artifacts, restricts UI/API exposure, documents credential review, and adds safe config or dependency policy checks.
  • Or a TRIAGE.md file that lists inspected package files/config, owner, observed version, UI/API exposure boundary, mounted files/secrets, required fix, and residual risk.
  • The output must include exact validation commands and must not read sensitive files, exercise RCE paths, expose tokens, or connect to live network-reachable test servers during triage.

Verification - what the reviewer looks for

  • No controlled package manifest, lockfile, devcontainer, CI image, SBOM, or generated report resolves vitest <4.1.0.
  • Vitest UI/API servers are loopback-only unless a reviewed exception is present.
  • Network-reachable exceptions explicitly disable privileged write and execute operations.
  • CI and remote-workspace jobs that start Vitest UI/API do not hold long-lived publish, deploy, cloud, or repository-write credentials.
  • Tests or policy checks catch stale package pins and accidental host exposure without executing exploit-like API calls.

Watch for

  • Fixing vitest in one workspace while another package or devcontainer still installs an older copy.
  • Treating local UI as safe when it is actually forwarded through a remote IDE, devcontainer, VPN, or tunnel.
  • Leaving allowWrite or allowExec enabled on a non-loopback API server.
  • Running interactive UI/API servers in the same jobs that publish packages, deploy services, or hold repository-write tokens.
  • Validation scripts that read files or hit Vitest API endpoints in ways that resemble the exploit instead of checking configuration safely.

References