Security changelog

Summary

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.

Summary

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.

Summary

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

Summary

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.

Summary

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

Summary

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

Summary

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.

Summary

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)

Summary

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

Summary

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

Summary

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

Summary

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)

Summary

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

Summary

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

Summary

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.

Summary

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.

Summary

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)

Summary

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

Summary

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

Summary

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.

Summary

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.

Summary

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

Summary

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.

Summary

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.

Summary

Vite dev server option server.fs.deny can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows.

This bypass is similar to https://nvd.nist.gov/vuln/detail/CVE-2023-34092 -- with surface area reduced to hosts having case-insensitive filesystems.

Patches

Fixed in vite@5.0.12, vite@4.5.2, vite@3.2.8, vite@2.9.17

Summary

When Vite’s HTML transformation is invoked manually via server.transformIndexHtml, the original request URL is passed in unmodified, and the html being transformed contains inline module scripts (<script type="module">...</script>), it is possible to inject arbitrary HTML into the transformed output by supplying a malicious URL query string to server.transformIndexHtml.

Impact

Only apps using appType: 'custom' and using the default Vite HTML middleware are affected.

The issue involves a security vulnerability in Vite where the server options can be bypassed using a double forward slash (//). This vulnerability poses a potential security risk as it can allow unauthorized access to sensitive directories and files.

Vite before v2.9.13 was discovered to allow attackers to perform a directory traversal via a crafted URL to the victim’s service.