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
29 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The contents of files that are specified by `server.fs.deny` can be returned to the browser. This is the same as https://github.com/vitejs/vite/security/advisories/GHSA-v2wj-q39q-566r. 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` - the sensitive file is denied with a pattern that matches a file by `server.fs.deny` Details On the Vite dev server, files that should be blocked by `server.fs.deny` (e.g., `.env`, `*.crt`) can be retrieved with HTTP 200 responses when query parameters such as `?raw`, `?import&raw`, or…
Recommended action: Upgrade to 6.4.5 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 8.3.3, 8.2.4, 8.1.6 or 2 more by release line, 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 8.3.3, 8.2.4, 8.1.6 or 2 more by release line, 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 8.3.3 or 8.2.4 by release line, 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 8.3.3, 8.2.4, 8.1.6 or 2 more by release line, 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 8.3.3, 8.2.4, 8.1.6 or 2 more by release line, 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 8.3.3, 8.2.4, 8.1.6 or 2 more by release line, 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 8.0.16, 7.3.5 or 6.4.3 by release line, 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 8.0.16, 7.3.5 or 6.4.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to the insufficient sanitization of the file argument in the launchEditor, an attacker can execute arbitrary commands on Windows by supplying a filename that contains special characters. Impact If the following conditions are met, an attacker can execute arbitrary commands on the computer that is using the launch-editor: - An attacker can place a file with the malicious filename - An attacker can call the launchEditor method with the file argument controlled - The launch-editor package is running on Windows For example, some development server using this package satisfy these conditions, as a malicious website might be able to force the downloading of a file and the path of that file is predictable. Patch This issue has been fixed in the launch-editor version 2.9.0 (commit).
Recommended action: Upgrade to 5.4.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any files ending with .map even out side the project can be returned to the browser. 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) - have a sensitive content in files ending with .map and the path is predictable Details In Vite v7.3.1, the dev server’s handling of .map requests for optimized dependencies resolves file paths and calls readFile without restricting ../ segments in the URL. As a result, it is possible to bypass the server.fs.strict allow list and retrieve .map files located outside the project root, provided they can be parsed as valid source map JSON. PoC 1. Create a minimal PoC sourcemap outside the project root 2. Start the Vite dev server (example) 3. Confirm that direct /@fs access is blocked by strict (returns 403) <img width="4004" height="1038" alt="image"…
Recommended action: Upgrade to 8.0.5, 7.3.2 or 6.4.2 by release line, 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. 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 - the sensitive file is denied with a pattern that matches a file by server.fs.deny Details On the Vite dev server, files that should be blocked by server.fs.deny (e.g., .env, .crt) can be retrieved with HTTP 200 responses when query parameters such as ?raw, ?import&raw, or ?import&url&inline are appended. PoC 1. Start the dev server: pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPort 2. Confirm that server.fs.deny is enforced (expect 403): curl -i http://127.0.0.1:5175/src/.env | head -n 20 <img width="3944" height="1092" alt="image" src="https://github.com/user-attachments/assets/ecb9f2e0-e08f-4ac7-b194-e0f988c4cd4f" / 3.…
Recommended action: Upgrade to 8.0.5 or 7.3.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
server.fs check was not enforced to the fetchModule method that is exposed in Vite dev server's WebSocket. 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) - WebSocket is not disabled by server.ws: false Arbitrary files on the server (development machine, CI environment, container, etc.) can be exposed. Details If it is possible to connect to the Vite dev server’s WebSocket without an Origin header, an attacker can invoke fetchModule via the custom WebSocket event vite:invoke and combine file://... with ?raw (or ?inline) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g., export default "..."). The access control enforced in the HTTP request path (such as server.fs.allow) is not applied to this WebSocket-based execution path. PoC 1. Start the dev server on the target Example (used during validation with this repository): 2.…
Recommended action: Upgrade to 8.0.5, 7.3.2 or 6.4.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Files denied by `server.fs.deny` were sent if the URL ended with `\` when the dev server is running 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) - running the dev server on Windows Details `server.fs.deny` can contain patterns matching against files (by default it includes `.env`, `.env.*`, `*.{crt,pem}` as such patterns). These patterns were able to bypass by using a back slash(`\`). The root cause is that `fs.readFile('/foo.png/')` loads `/foo.png`. PoC ```shell npm create vite@latest cd vite-project/ cat "secret" > .env npm install npm run dev curl --request-target /.env\ http://localhost:5173 ```
Recommended action: Upgrade to 7.1.11, 7.0.8, 6.4.1 or 5.4.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Files starting with the same name with the public directory were served bypassing the server.fs settings. 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) - uses the public directory feature (enabled by default) - a symlink exists in the public directory Details The servePublicMiddleware function is in charge of serving public files from the server. It returns the viteServePublicMiddleware function which runs the needed tests and serves the page. The viteServePublicMiddleware function checks if the publicFiles variable is defined, and then uses it to determine if the requested page is public. In the case that the publicFiles is undefined, the code will treat the requested page as a public page, and go on with the serving function. publicFiles may be undefined if there is a symbolic link anywhere inside the public directory. In that case, every requested page…
Recommended action: Upgrade to 7.1.5, 7.0.7, 6.3.6 or 5.4.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any HTML files on the machine were served regardless of the server.fs settings. 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) - appType: 'spa' (default) or appType: 'mpa' is used This vulnerability also affects the preview server. The preview server allowed HTML files not under the output directory to be served. Details The serveStaticMiddleware function is in charge of serving static files from the server. It returns the viteServeStaticMiddleware function which runs the needed tests and serves the page. The viteServeStaticMiddleware function checks if the extension of the requested file is ".html". If so, it doesn't serve the page. Instead, the server will go on to the next middlewares, in this case htmlFallbackMiddleware, and then to indexHtmlMiddleware. These middlewares don't perform any test against allow or deny rules, and they don't make sure that…
Recommended action: Upgrade to 7.1.5, 7.0.7, 6.3.6 or 5.4.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The contents of files in the project root that are denied by a file matching pattern can be returned to the browser. Impact Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected. Only files that are under project root and are denied by a file matching pattern can be bypassed. - Examples of file matching patterns: .env, .env., .{crt,pem}, /.env - Examples of other patterns: /.git/, .git/, .git// Details server.fs.deny can contain patterns matching against files (by default it includes .env, .env., .{crt,pem} as such patterns). These patterns were able to bypass for files under root by using a combination of slash and dot (/.). PoC
Recommended action: Upgrade to 6.3.4, 6.2.7, 6.1.6 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
6.0.156.2.64.5.135.4.186.1.5· Vendor fix available
Issue
The contents of arbitrary files can be returned to the browser if the dev server is running on Node or Bun. Impact Only apps with the following conditions are affected. - explicitly exposing the Vite dev server to the network (using --host or server.host config option) - running the Vite dev server on runtimes that are not Deno (e.g. Node, Bun) Details HTTP 1.1 spec (RFC 9112) does not allow in request-target. Although an attacker can send such a request. For those requests with an invalid request-line (it includes request-target), the spec recommends to reject them with 400 or 301. The same can be said for HTTP 2 (ref1, ref2, ref3). On Node and Bun, those requests are not rejected internally and is passed to the user land. For those requests, the value of http.IncomingMessage.url contains #. Vite assumed req.url won't contain when checking server.fs.deny, allowing those kinds of requests to bypass the check. On Deno, those requests are not rejected internally and is…
Recommended action: Upgrade to 6.2.6, 6.1.5, 6.0.15 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
6.0.146.2.54.5.126.1.45.4.17· Vendor fix available
Issue
The contents of arbitrary files can be returned to the browser. Impact Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected. Details .svg Requests ending with .svg are loaded at this line. https://github.com/vitejs/vite/blob/037f801075ec35bb6e52145d659f71a23813c48f/packages/vite/src/node/plugins/asset.ts#L285-L290 By adding ?.svg with ?.wasm?init or with sec-fetch-dest: script header, the restriction was able to bypass. This bypass is only possible if the file is smaller than build.assetsInlineLimit (default: 4kB) and when using Vite 6.0+. relative paths The check was applied before the id normalization. This allowed requests to bypass with relative paths (e.g. ../../). PoC send request to read etc/passwd
Recommended action: Upgrade to 6.2.5, 6.1.4, 6.0.14 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
6.1.35.4.166.0.136.2.44.5.11· Vendor fix available
Issue
The contents of arbitrary files can be returned to the browser. Impact Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected. Details - base64 encoded content of non-allowed files is exposed using ?inline&import (originally reported as ?import&?inline=1.wasm?init) - content of non-allowed files is exposed using ?raw?import /@fs/ isn't needed to reproduce the issue for files inside the project root. PoC Original report (check details above for simplified cases): The ?import&?inline=1.wasm?init ending allows attackers to read arbitrary files and returns the file content if it exists. Base64 decoding needs to be performed twice Example full URL http://localhost:5173/@fs/C:/windows/win.ini?import&?inline=1.wasm?init
Recommended action: Upgrade to 6.2.4, 6.1.3, 6.0.13 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
6.2.35.4.154.5.106.1.26.0.12· Vendor fix available
Issue
The contents of arbitrary files can be returned to the browser. Impact Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected. Details @fs denies access to files outside of Vite serving allow list. Adding ?raw?? or ?import&raw?? to the URL bypasses this limitation and returns the file content if it exists. This bypass exists because trailing separators such as ? are removed in several places, but are not accounted for in query string regexes. PoC
Recommended action: Upgrade to 6.2.3, 6.1.2, 6.0.12 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vite allowed any websites to send any requests to the development server and read the response due to default CORS settings and lack of validation on the Origin header for WebSocket connections. [!WARNING] This vulnerability even applies to users that only run the Vite dev server on the local machine and does not expose the dev server to the network. Upgrade Path Users that does not match either of the following conditions should be able to upgrade to a newer version of Vite that fixes the vulnerability without any additional configuration. - Using the backend integration feature - Using a reverse proxy in front of Vite - Accessing the development server via a domain other than localhost or .localhost - Using a plugin / framework that connects to the WebSocket server on their own from the browser Using the backend integration feature If you are using the backend integration feature and not setting server.origin, you need to add the origin of the backend server to the…
Recommended action: Upgrade to 6.0.9, 5.4.12 or 4.5.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
5.2.145.4.65.3.63.2.114.5.45.1.8· Vendor fix available
Issue
We discovered a DOM Clobbering vulnerability in Vite when building scripts to cjs/iife/umd output format. The DOM Clobbering gadget in the module can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an img tag with an unsanitized name attribute) are present. Note that, we have identified similar security issues in Webpack: https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986 Details Backgrounds DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references: [1] https://scnps.co/papers/sp23domclob.pdf [2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/ Gadgets found in Vite We have…
Recommended action: Upgrade to 5.4.6, 5.3.6, 5.2.14 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
5.2.145.4.65.3.63.2.114.5.45.1.8· Vendor fix available
Issue
The contents of arbitrary files can be returned to the browser. Details @fs denies access to files outside of Vite serving allow list. Adding ?import&raw to the URL bypasses this limitation and returns the file content if it exists. PoC
Recommended action: Upgrade to 5.4.6, 5.3.6, 5.2.14 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
3.2.105.0.134.5.35.2.65.1.72.9.18· Vendor fix available
Issue
Vite dev server option server.fs.deny did not deny requests for patterns with directories. An example of such a pattern is /foo//. Impact Only apps setting a custom server.fs.deny that includes a pattern with directories, and explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected. Patches Fixed in vite@5.2.6, vite@5.1.7, vite@5.0.13, vite@4.5.3, vite@3.2.10, vite@2.9.18 Details server.fs.deny uses picomatch with the config of { matchBase: true }. matchBase only matches the basename of the file, not the path due to a bug (https://github.com/micromatch/picomatch/issues/89). The vite config docs read like you should be able to set fs.deny to glob with picomatch. Vite also does not set { dot: true } and that causes dotfiles not to be denied unless they are explicitly defined. Reproduction Set fs.deny to ['/.git/'] and then curl for /.git/config. with matchBase: true, you can get any file under .git/ (config, HEAD, etc).…
Recommended action: Upgrade to 5.2.6, 5.1.7, 5.0.13 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.