CVE-2026-112948

CVE-2026-112948 is a medium-severity security vulnerability in @vitest/ui (npm), affecting versions >= 5.0.0-beta.6, < 5.0.5. It is fixed in 5.0.5, 1.3.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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.

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:

export default defineConfig({
  server: {
    fs: {
      deny: [
        '.env',
        '.env.*',
        '*.{crt,pem,key,p12,pfx,cer,der}',
        '.npmrc',
        '.yarnrc.yml',
        '**/.git/**',
        '.vitest-secret-token',
      ],
    },
  },
})

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.

CVE-2026-112948 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (5.0.5, 1.3.0); upgrading removes the vulnerable code path.

Affected versions

@vitest/ui (>= 5.0.0-beta.6, < 5.0.5) @vitest/browser (>= 5.0.0-beta.6, < 5.0.5) vite-plus (>= 1.0.0-rc.0, < 1.3.0)

Security releases

@vitest/ui → 5.0.5 (npm) @vitest/browser → 5.0.5 (npm) vite-plus → 1.3.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

@vitest/ui to 5.0.5 or later; @vitest/browser to 5.0.5 or later; vite-plus to 1.3.0 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-112948? CVE-2026-112948 is a medium-severity security vulnerability in @vitest/ui (npm), affecting versions >= 5.0.0-beta.6, < 5.0.5. It is fixed in 5.0.5, 1.3.0.
  2. How severe is CVE-2026-112948? CVE-2026-112948 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by CVE-2026-112948?
    • @vitest/ui (npm) (versions >= 5.0.0-beta.6, < 5.0.5)
    • @vitest/browser (npm) (versions >= 5.0.0-beta.6, < 5.0.5)
    • vite-plus (npm) (versions >= 1.0.0-rc.0, < 1.3.0)
  4. Is there a fix for CVE-2026-112948? Yes. CVE-2026-112948 is fixed in 5.0.5, 1.3.0. Upgrade to this version or later.
  5. Is CVE-2026-112948 exploitable, and should I be worried? Whether CVE-2026-112948 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-112948 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-112948?
    • Upgrade @vitest/ui to 5.0.5 or later
    • Upgrade @vitest/browser to 5.0.5 or later
    • Upgrade vite-plus to 1.3.0 or later

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo