Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
@vitest/mocker's interceptorPlugin accepts mock registrations on Vite's dev-server WebSocket with no authentication, and interpolates the mock's url into generated module source without escaping. A client that can reach the dev server can make it serve arbitrary JavaScript in place of any project module, which then runs in the developer's browser on the dev-server origin. Same handler and same unauthenticated caller as GHSA-82fw-gwwq-j7x9; that fix (8ff9b9a9efca7c6cfd5243569440de8d7a33aec4, PR #10972) hardened only the redirect branch and left the manual branch reaching the unescaped generator. Patches Fixed in @vitest/mocker 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. createManualModuleSource now serializes the module URL and the export names with JSON.stringify, so a registered mock cannot change the generated code. Projects that call mockerPlugin() or interceptorPlugin() directly need @vitest/mocker 4.1.12 or 5.0.3. Details…
Recommended action: Upgrade to 5.0.3 or 4.1.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The path traversal fix released for GHSA-82fw-gwwq-j7x9 can be bypassed on Windows by using a backslash in the redirect URL pathname. The fixed code joins an attacker-controlled URL pathname with the Vite root using node:path/posix, then passes that string to Vite's file allowlist check. On Windows, a value such as C:/project/root/..\secret.txt retains ..\ during the POSIX join and begins with the allowed root, so the allowlist accepts it. The later readFile() call uses Windows filesystem semantics, where the backslash is a path separator, and reads the sibling file outside the configured root. I reproduced the issue with the published @vitest/mocker packages in both fixed release lines: - @vitest/mocker@4.1.11 - @vitest/mocker@5.0.0 The current main source at commit 2ce29d5fa758046e5453bd92b8ed6c9da9709bb5 has the same behavior. Patches Fixed in @vitest/mocker 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. The redirect registration now converts…
Recommended action: Upgrade to 5.0.3 or 4.1.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
@vitest/mocker registers a redirect mock's target path without validating it against 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 load hook returns readFile(<attacker path) as the module source, disclosing local files. This is exploitable without authentication only through the public mockerPlugin / standalone interceptorPlugin exports (used by third-party dev servers), 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 load hook is the file-read sink: mock.redirect is derived from client input at registration time with no boundary check: There is no server.fs.allow / server.fs.deny check and no assertion that the…
Recommended action: Upgrade to 5.0.0-rc.2 (pre-release) or 4.1.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.