返回资讯中心
外部精选
软件工程
#开发者实时流

Vitest Dev Server Secret Leak (CVE-2026-112948)

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)…

Hacker News 最新mumairrana0072026/10/22 · 15 天前14 分钟阅读

以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。

@vitest/browser (npm)

Affected versions

= 5.0.0-beta.6, < 5.0.5

Patched versions

5.0.5

npm

@vitest/ui (npm)

= 5.0.0-beta.6, < 5.0.5

5.0.5

npm

vite-plus (npm)

= 1.0.0-rc.0, < 1.3.0

1.3.0

Description

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.

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.

Information disclosure from the Vitest dev server, and with the token, privileged API access.

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.

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', ], }, }, })

References

GHSA-p458-7748-mcp3

https://nvd.nist.gov/vuln/detail/CVE-2026-112948

vitest-dev/vitest#11578

vitest-dev/vitest@28dc1ed

https://github.com/vitest-dev/vitest/releases/tag/v5.0.5

sheremet-va published to

vitest-dev/vitest

Oct 16, 2026

Published by the National Vulnerability Database Oct 20, 2026

Published to the GitHub Advisory Database Oct 21, 2026

Reviewed Oct 21, 2026

Last updated Oct 21, 2026

Severity

Moderate

6.5

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).

/ 10

CVSS v3 base metrics

Attack vector Network

Attack complexity Low

Privileges required None

User interaction Required

Scope Unchanged

Confidentiality High

Integrity None

Availability None

Learn more about base metrics

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.

Attack complexity: More severe for the least complex attacks.

Privileges required: More severe if no privileges are required.

User interaction: More severe when no user interaction is required.

Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.

Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.

Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.

Availability: More severe when the loss of impacted component availability is highest.

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

EPSS score

0.406%

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.

(34th percentile)

Weaknesses

Weakness CWE-200

Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Learn more on MITRE.

Weakness CWE-552

Files or Directories Accessible to External Parties

The product makes files or directories accessible to unauthorized actors, even though they should not be. Learn more on MITRE.

CVE ID

CVE-2026-112948

GHSA ID

GHSA-p458-7748-mcp3

Source code

vitest-dev/vitest

Credits

sondt99

Reporter

tomohiro86

Finder

Loading

Checking history

Uh oh!

There was an error while loading. Please reload this page.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →