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
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.…
Recommended action: Upgrade to 1.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When accessing a malicious site while a dev server using Vite is running, that site was able to load scripts in a page served by the dev server. Impact Only apps that match the following conditions are affected: - the dev server passes an unchanged browser request URL to server.transformIndexHtml: this is normally used for server.middlewareMode: true or appType: 'custom'. The internal call for appType: 'spa' and appType: 'mpa' does not match this. - the transformed HTML contains an inline module script - from the script in the page served by the dev server, the app stores sensitive values in the location accessible or allows critical actions Details Vite's SSR guide for 8.2.1 documents the affected setup. The application embeds Vite in middleware mode, reads trusted HTML, and passes the browser's unchanged request URL to the transform: For a development server at http://localhost:5173, an attacker can send this URL: In Vite 8.2.1, createDevHtmlTransformFn and getHtmlFilename…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The content of files outside server.fs setting can be returned to the browser if the project imports a file path concatenated with the root. For example, if the project references <path-to-project-root/etc/hosts, the content of /etc/hosts was possible to be returned. The content of files outside the server.fs.allow option can be returned to the browser when a project imports a file whose root-relative path matches an absolute path on the host. For example, referencing <project-root/etc/hosts could make Vite return the host's /etc/hosts file. Impact Only apps that meet all of the following conditions are affected: - explicitly expose the Vite dev server to the network (using --host or the server.host option) - contain an imported file whose root-relative browser URL is also the absolute path of a readable file on the host - The sensitive file is not matched by server.fs.deny - the dev server is not running on Windows Details When Vite analyzes an in-root import, it rewrites…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The first 4 bytes of files outside of server.fs setting can be returned to the browser by a request containing ?vite-wasm-instance. Impact Only apps that match one of the following conditions are affected: - explicitly expose the Vite dev server to the network using --host or the server.host option - there's a file that has a sensitive information in the first 4 bytes - uses Node.js or Deno to run Vite (if Bun is used, it is not affected) Details Requests containing the ?vite-wasm-instance query are handled by the internal Wasm plugin's load hook. The hook removes the query and reads the resulting path directly from disk, but the server.fs checks were not applied. After reading the file, Vite attempts to parse it as WebAssembly. When that parse fails, Node and deno throws an error that contains the first 4 bytes of the file. PoC Create a denied file and start an affected Vite dev server: This will show
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
launch-editor forwarded file paths directly to editors without sanitization. If a path resembles a CLI flag, editors like Vim may interpret it as a command, potentially causing unintended file overwrites or command execution. Impact Direct launch-editor users Only apps that match all of the following conditions are affected: - The attacker is able to create a file system entry (e.g. a file or directory) starting with + or - in the working directory - The user uses or the app specifies any of the following editors: - Vim (including gVim) - MacVim - Emacs (including Emacsclient) - Notepad++ (only if using a plugin exposing dangerous operations via plugin messages) - The first argument of launchEditor can start with + or - or the user is using WSL launch-editor-middleware users Only apps that match the following conditions are affected: - The attacker is able to create a file system entry (e.g. a file or directory) starting with + or - in the working directory - The user uses or…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
launch-editor checked fs.existsSync(fileName) before passing a supplied path to an editor command. On Windows, an attacker can bypass this check with a crafted path ending in \\..:line:column. This removes the requirement that the attacker be able to place a file with a malicious filename. Combined with the % escaping issue described in GHSA-698v-4r3x-3vcv, this bypass can lead to OS command injection when an attacker controls the file argument. Impact Only apps that runs on Windows is affected. Details The earlier advisory assumed that fs.existsSync() required an attacker-controlled filename to exist. This advisory covers a bypass of that requirement. A crafted value ending in \\..:1:1 is interpreted differently by launch-editor-middleware, launch-editor, and Windows: 1. launch-editor-middleware calls path.resolve() while the final path component is ..:1:1, so it is not treated as a parent-directory component. 2. launch-editor treats :1:1 as a line-and-column suffix and…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
launch-editor did not escape % on Windows when passing an argument to cmd. When an environment variable contained a malicious value, it was possible that that content to be executed. Impact Only apps that match all of the following conditions are affected: - The user uses Windows - An attacker can place a file with the malicious filename containing & or % - Either of - An attacker can inject an environment variable with a malicious value - An attacker can add a NTFS alternate data stream to the file placed Details Unlike .sh files, .bat / .cmd files on Windows cannot be called directly using childprocess.spawn and requires passing them as an argument of cmd.exe. To do so, launch-editor escapes the arguments passed to cmd.exe. But launch-editor did not escape % which is used for environment variables. Because launch-editor checks if the argument matches an existing filename, the attack requires the attacker to be able to place a file. - If the attacker can inject an…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vitest Browser Mode exposes a cdp() API that forwards raw Chrome DevTools Protocol (CDP) methods over the Vitest browser WebSocket RPC. CDP is not gated by browser.api.allowWrite, browser.api.allowExec, api.allowWrite, or api.allowExec. As a result, disabling Browser Mode write and exec operations does not prevent a browser API client from using CDP to perform equivalent actions. In a verified reproduction with allowWrite: false and allowExec: false, CDP Page.setDownloadBehavior set the browser download directory to the project root, and CDP Runtime.evaluate downloaded a controlled vite.config.ts. Vitest reloaded the changed config and executed attacker-controlled Node.js code. When the Browser Mode API is also exposed to the network, this becomes remotely exploitable because the generated browser runner page exposes the API token, active session id, project name, and project root path needed to connect to the browser WebSocket API and select the target download directory.…
Recommended action: Upgrade to 0.1.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The launch-editor NPM package accesses arbitrary paths including Windows UNC paths. When a UNC path is opened, Windows automatically attempts NTLM authentication to the remote host, causing the user’s NTLMv2 password hash to be leaked to an attacker-controlled SMB server. This can result in credential compromise through offline hash cracking. Impact If the following conditions are met, an attacker can get the NTLMv2 password hash on the computer that is using the launch-editor: - using Windows - NTLM is not disabled (it is recommended to disable, while it's still enabled by default) - the user accesses the attackers website that sends request to a middleware using launch-editor - the server that has the middleware using launch-editor is running - the attacker knows the URL for that server and the middleware This would be a problem if the user password is too simple that it can be identified through offline hash cracking, potentially leading to further compromise of developer…
Recommended action: Upgrade to 0.1.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The contents of files that are specified by `server.fs.deny` can be returned to the browser on Windows. Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using `--host` or `server.host` config option) - the sensitive file exists in the allowed directories specified by `server.fs.allow` - either of: - the sensitive file exists in an NTFS volume - the dev server is running on Windows and the sensitive file exists in a volume that 8.3 short name generation is enabled (it is enabled by default on system volumes) Details Vite’s dev server denies direct access to sensitive files through `server.fs.deny`, including entries such as `.env`, `.env.*`, and `*.{crt,pem}`. However, on Windows, the deny logic does not correctly…
Recommended action: Upgrade to 0.1.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
downloadPackageManager() in vite-plus/binding accepts an untrusted version string and uses it directly in filesystem paths. A caller can supply ../ segments to escape the VPHOME/packagemanager/<pm/ cache root and cause Vite+ to delete, replace, and populate directories outside the intended cache location. Details The public vite-plus/binding export downloadPackageManager() forwards options.version directly into the Rust package-manager download flow without validating that it is a normal semver version. That value is used as a path component when building the install location under VPHOME. After the package is downloaded and extracted, Vite+: 1. computes the final target directory from the raw version string, 2. removes any pre-existing directory at that target, 3. renames the extracted package into that location, and 4. writes executable shim files there. Because the CLI validates versions via semver::Version::parse() before calling this code, the protection that exists for…
Recommended action: Upgrade to 0.1.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.