chore(deps): update dependency vitest to v4 [security] #15
Inga granskare
Etiketter
Inga etiketter
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
supernaut/next-image-storyblok-loader!15
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "renovate/npm-vitest-vulnerability"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
This PR contains the following updates:
^3.2.1→^4.0.0When Vitest UI server is listening, arbitrary file can be read and executed
CVE-2026-47429 / GHSA-5xrq-8626-4rwp
More information
Details
Summary
Arbitrary file can be read on Windows when Vitest UI server is listening, especially when exposed to the network.
Impact
Only users that match either of the following conditions are affected:
--api.hostorapi.hostconfig option)Details
The API handler for
/__vitest_attachment__uses the deprecatedisFileServingAllowedincorrectly.github.com/vitest-dev/vitest@eb1abf0857/packages/ui/node/index.ts (L77)The function expects the passed value to use
cleanUrlafter the check before file system related operation.Because of this, it is possible to bypass the check by
\\?\\..\\. This is not possible on Linux as Linux errors if a directory named?does not exist.A similar problem exists in other places as well.
github.com/vitest-dev/vitest@eb1abf0857/packages/vitest/src/api/setup.ts (L103-L105)github.com/vitest-dev/vitest@eb1abf0857/packages/vitest/src/api/setup.ts (L119-L121)github.com/vitest-dev/vitest@eb1abf0857/packages/browser/src/node/commands/fs.ts (L10-L11)github.com/vitest-dev/vitest@eb1abf0857/packages/browser/src/node/plugin.ts (L194-L196)github.com/vitest-dev/vitest@eb1abf0857/packages/browser/src/node/rpc.ts (L115-L121)That said, this
isFileServingAllowedcheck does not actually prevent the API to be abused. Since the API has rerun feature and file write feature, it's possible to run arbitrary script by writing a script as a test file usingsaveTestFileand running it usingrerun. This means exposing the API / Vitest UI is equivalent to giving script execution access.On the browser mode side, there're
readFile/writeFile/saveSnapshotFile. So exposing the browser mode is equivalent to giving file read / write access.PoC
curl http://localhost:51204/__vitest__/curl "http://localhost:51204/__vitest_attachment__?path=C:\\path\\to\\project\\?\\..\\..\\secret.txt&contentType=text/plain&token=$TOKEN"(TOKEN is the API token)secret.txtthat is outside the project directoryMitigations
Vitest now ships two configuration flags,
allowWriteandallowExec, that gate the privileged operations exploited by this vulnerability. Both are disabled by default whenever the API server is bound to a non-localhosthost, ensuring that exposing the server to the network no longer implicitly grants write or execute capabilities to remote clients.When these flags are disabled, the UI also enters a read-only mode: in-browser code editing and test file execution are turned off, removing the attack surface that allowed remote code execution. Many Browser Mode features are also disabled, like attachments, artifacts or snapshots. See
browser.api.Users who require the full interactive UI on a networked host must explicitly opt in by setting
allowWriteand/orallowExectotrue.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Vitest: Path Traversal / Arbitrary File Read via @vitest/mocker Redirect Mock
CVE-2026-84373 / GHSA-82fw-gwwq-j7x9
More information
Details
Summary
@vitest/mockerregisters a redirect mock's target path without validating itagainst the dev server's file-serving allowlist. An attacker who can reach the
dev server's WebSocket can register a redirect mock pointing outside the project
root; when the mocked module is requested, the plugin's
loadhook returnsreadFile(<attacker path>)as the module source, disclosing local files.This is exploitable without authentication only through the public
mockerPlugin/ standaloneinterceptorPluginexports (used by third-party devservers), which register the handler on Vite's unauthenticated HMR socket.
Vitest's own browser mode registers mocks over a token-authenticated RPC and
is not remotely reachable by default (see Scope).
Affected code
packages/mocker/src/node/interceptorPlugin.ts.The
loadhook is the file-read sink:mock.redirectis derived from client input at registration time with noboundary check:
There is no
server.fs.allow/server.fs.denycheck and no assertion that theresolved path stays within the project root.
Registration paths and trust boundaries
mockerPlugin/interceptorPlugin(unauthenticated). InconfigureServer, the plugin registersserver.ws.on('vitest:interceptor:register', …)on Vite's HMR WebSocket. That socket performs no token, Origin, or same-origin
check, so any client that can reach it can register a redirect mock. This is
the path the "unauthenticated" impact applies to.
(
registerMock), which sits behind a per-run token (isValidApiRequest, arandom
api.token). The interceptor'sconfigureServersocket is not used forregistration here (in v5 it does not run at all, as the plugin is injected per
environment). The same missing boundary check exists on the authenticated RPC
path, but reaching it requires the token, so it is not a remote-unauthenticated
read.
Path handling
new URL(redirect).pathnamecombined withjoin(root, pathname)does notconfine reads to the root:
file:,http:) are normalized by WHATWG URL,so
..segments are collapsed and the result stays under the root. Payloads ofthe form
file:///../../etc/passwddo not escape...inpathname, sojoin(root, "../../…/etc/passwd")resolves outside the root and reads anarbitrary file.
Even without escaping the root, the missing
server.fscheck allows reading anyin-root file the dev server would otherwise refuse to serve (for example an
in-root
.envor source that is denied byserver.fs.deny).Scope / preconditions
localhostbydefault and is not reachable from the network unless the developer exposes it
(
server.host/0.0.0.0, a LAN bind, or a proxy).and CORS protections entirely and can both register the mock and read the
response.
by Vite defaults: the default CORS origin allowlist is limited to
localhostorigins, and
server.allowedHostsblocks DNS-rebinding, so a cross-origin pagecannot read the file contents back.
Impact
Disclosure of local files readable by the dev-server process (source, in-root
.env/secrets, and, via the opaque-scheme payload, files outside the projectroot). No integrity or availability impact.
Affected versions
Present since
@vitest/mockerwas introduced.@vitest/mocker>= 2.1.0 (shipped invitestand@vitest/browser>= 2.1.0), through 4.1.x and the 5.0.0 pre-releases.maintained and are not planned to receive the fix.
Fix
Validate the resolved redirect target against Vite's file-serving allowlist
(
isFileLoadingAllowed) before registering it, at every registration site, andstop registering the interceptor WebSocket events in Vitest's browser mode
(mocks there flow through the authenticated RPC).
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (in timezone Europe/Stockholm)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.
Visa kommandoradsinstruktioner
Checka ut
Checka ut en ny gren från din projektkatalog och testa ändringarna.