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.
Steps to Fix. Update Vite: Ensure that you are using the latest version of Vite. Security issues like this are often fixed in newer releases.\n2. Secure the server configuration: In your vite.config.js file, review and update the server configuration options to restrict access to unauthorized requests or directories.
Impact
Only users explicitly exposing the Vite dev server to the network (using --host or the server.host config option) are affected and only files in the immediate Vite project root folder could be exposed.\n\n### Patches\nFixed in vite@4.3.9, vite@4.2.3, vite@4.1.5, vite@4.0.5 and in the latest minors of the previous two majors, vite@3.2.7 and vite@2.9.16.
Details
Vite serves the application with under the root-path of the project while running on the dev mode. By default, Vite uses the server option fs.deny to protect sensitive files. But using a simple double forward-slash, we can bypass this restriction. \n\n### PoC\n1. Create a new latest project of Vite using any package manager. (here I'm using react and vue templates and pnpm for testing)\n2. Serve the application on dev mode using pnpm run dev.\n3. Directly access the file via url using double forward-slash (//) (e.g: //.env, //.env.local)\n4. The server option fs.deny was successfully bypassed.
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 HTML entry must also contain an inline script. The attack requires a user to click on a malicious URL while running the dev server. Restricted files aren't exposed to the attacker.
Patches
Fixed in vite@5.0.5, vite@4.5.1, vite@4.4.12
Details
Suppose index.html contains an inline module script:
<script type="module">
// Inline script
</script>
This script is transformed into a proxy script like
so the url passed to server.transformIndexHtml is /index.html.
However, if appType: 'custom', HTML is served manually, and if server.transformIndexHtml is called with the unmodified request URL (as the SSR docs suggest), then the path of the transformed html-proxy script varies with the request URL. For example, a request with path / produces
However, since this vulnerability affects server.transformIndexHtml, the scope of impact may be higher to also include other ad-hoc calls to server.transformIndexHtml from outside of Vite's own codebase.
My best guess at bisecting which versions are vulnerable involves the following test script
import fs from 'node:fs/promises';
import * as vite from 'vite';
const html = `
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
</head>
<body>
<script type="module">
// Inline script
</script>
</body>
</html>
`;
const server = await vite.createServer({ appType: 'custom' });
const transformed = await server.transformIndexHtml('/?%22%3E%3C/script%3E%3Cscript%3Ealert(%27boom%27)%3C/script%3E', html);
console.log(transformed);
await server.close();
and using it I was able to narrow down to #13581. If this is correct, then vulnerable Vite versions are 4.4.0-beta.2 and higher (which includes 4.4.0).
Vite dev server optionserver.fs.deny can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows.
Vite dev server optionserver.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).
with matchBase: false, you cannot get any file under .git/ (config, HEAD, etc).
Release Notes
vitejs/vite (vite)
### [`v4.5.3`](https://togithub.com/vitejs/vite/compare/v4.5.2...aac695e9f8f29da43c2f7c50c549fa3d3dfeeadc)
[Compare Source](https://togithub.com/vitejs/vite/compare/v4.5.2...v4.5.3)
### [`v4.5.2`](https://togithub.com/vitejs/vite/releases/tag/v4.5.2)
[Compare Source](https://togithub.com/vitejs/vite/compare/v4.5.1...v4.5.2)
Please refer to [CHANGELOG.md](https://togithub.com/vitejs/vite/blob/v4.5.2/packages/vite/CHANGELOG.md) for details.
### [`v4.5.1`](https://togithub.com/vitejs/vite/releases/tag/v4.5.1)
[Compare Source](https://togithub.com/vitejs/vite/compare/v4.5.0...v4.5.1)
Please refer to [CHANGELOG.md](https://togithub.com/vitejs/vite/blob/v4.5.1/packages/vite/CHANGELOG.md) for details.
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, check this box
This PR contains the following updates:
4.5.0
->4.5.3
GitHub Vulnerability Alerts
CVE-2023-34092
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.Steps to Fix. Update Vite: Ensure that you are using the latest version of Vite. Security issues like this are often fixed in newer releases.\n2. Secure the server configuration: In your
vite.config.js
file, review and update the server configuration options to restrict access to unauthorized requests or directories.Impact
Only users explicitly exposing the Vite dev server to the network (using
--host
or theserver.host
config option) are affected and only files in the immediate Vite project root folder could be exposed.\n\n### Patches\nFixed in vite@4.3.9, vite@4.2.3, vite@4.1.5, vite@4.0.5 and in the latest minors of the previous two majors, vite@3.2.7 and vite@2.9.16.Details
Vite serves the application with under the root-path of the project while running on the dev mode. By default, Vite uses the server option fs.deny to protect sensitive files. But using a simple double forward-slash, we can bypass this restriction. \n\n### PoC\n1. Create a new latest project of Vite using any package manager. (here I'm using react and vue templates and pnpm for testing)\n2. Serve the application on dev mode using
pnpm run dev
.\n3. Directly access the file via url using double forward-slash (//
) (e.g://.env
,//.env.local
)\n4. The server optionfs.deny
was successfully bypassed.Proof Images: \n
CVE-2023-49293
Summary
When Vite's HTML transformation is invoked manually via
server.transformIndexHtml
, the original request URL is passed in unmodified, and thehtml
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 toserver.transformIndexHtml
.Impact
Only apps using
appType: 'custom'
and using the default Vite HTML middleware are affected. The HTML entry must also contain an inline script. The attack requires a user to click on a malicious URL while running the dev server. Restricted files aren't exposed to the attacker.Patches
Fixed in vite@5.0.5, vite@4.5.1, vite@4.4.12
Details
Suppose
index.html
contains an inline module script:This script is transformed into a proxy script like
due to Vite's HTML plugin:
https://github.com/vitejs/vite/blob/7fd7c6cebfcad34ae7021ebee28f97b1f28ef3f3/packages/vite/src/node/plugins/html.ts#L429-L465
When
appType: 'spa' | 'mpa'
, Vite serves HTML itself, andhtmlFallbackMiddleware
rewritesreq.url
to the canonical path ofindex.html
,https://github.com/vitejs/vite/blob/73ef074b80fa7252e0c46a37a2c94ba8cba46504/packages/vite/src/node/server/middlewares/htmlFallback.ts#L44-L47
so the
url
passed toserver.transformIndexHtml
is/index.html
.However, if
appType: 'custom'
, HTML is served manually, and ifserver.transformIndexHtml
is called with the unmodified request URL (as the SSR docs suggest), then the path of the transformedhtml-proxy
script varies with the request URL. For example, a request with path/
producesIt is possible to abuse this behavior by crafting a request URL to contain a malicious payload like
so a request to http://localhost:5173/?%22%3E%3C/script%3E%3Cscript%3Ealert(%27boom%27)%3C/script%3E produces HTML output like
which demonstrates XSS.
PoC
vite dev
middleware withappType: 'custom'
?%22%3E%3C/script%3E%3Cscript%3Ealert(%27boom%27)%3C/script%3E
and navigatevite dev
(this shows that vanillavite dev
is not vulnerable, providedhtmlFallbackMiddleware
is used)Detailed Impact
This will probably predominantly affect development-mode SSR, where
vite.transformHtml
is called using the originalreq.url
, per the docs:https://github.com/vitejs/vite/blob/7fd7c6cebfcad34ae7021ebee28f97b1f28ef3f3/docs/guide/ssr.md?plain=1#L114-L126
However, since this vulnerability affects
server.transformIndexHtml
, the scope of impact may be higher to also include other ad-hoc calls toserver.transformIndexHtml
from outside of Vite's own codebase.My best guess at bisecting which versions are vulnerable involves the following test script
and using it I was able to narrow down to #13581. If this is correct, then vulnerable Vite versions are 4.4.0-beta.2 and higher (which includes 4.4.0).
CVE-2024-23331
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
Details
Since
picomatch
defaults to case-sensitive glob matching, but the file server doesn't discriminate; a blacklist bypass is possible.See
picomatch
usage, wherenocase
is defaulted tofalse
: https://github.com/vitejs/vite/blob/v5.1.0-beta.1/packages/vite/src/node/server/index.ts#L632By requesting raw filesystem paths using augmented casing, the matcher derived from
config.server.fs.deny
fails to block access to sensitive files.PoC
Setup
npm create vite@latest
on a Standard Azure hosted Windows 10 instance.npm run dev -- --host 0.0.0.0
custom.secret
andproduction.pem
vite.config.js
withReproduction
curl -s http://20.12.242.81:5173/@​fs//
curl -s http://20.12.242.81:5173/@​fs/C:/Users/darbonzo/Desktop/vite-project/vite.config.js
curl -s http://20.12.242.81:5173/@​fs/C:/Users/darbonzo/Desktop/vite-project/custom.sEcReT
Proof
Impact
Who
What
server.fs.deny
are both discoverable, and accessibleCVE-2024-31207
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
orserver.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
.matchBase: true
, you can get any file under.git/
(config, HEAD, etc).matchBase: false
, you cannot get any file under.git/
(config, HEAD, etc).Release Notes
vitejs/vite (vite)
### [`v4.5.3`](https://togithub.com/vitejs/vite/compare/v4.5.2...aac695e9f8f29da43c2f7c50c549fa3d3dfeeadc) [Compare Source](https://togithub.com/vitejs/vite/compare/v4.5.2...v4.5.3) ### [`v4.5.2`](https://togithub.com/vitejs/vite/releases/tag/v4.5.2) [Compare Source](https://togithub.com/vitejs/vite/compare/v4.5.1...v4.5.2) Please refer to [CHANGELOG.md](https://togithub.com/vitejs/vite/blob/v4.5.2/packages/vite/CHANGELOG.md) for details. ### [`v4.5.1`](https://togithub.com/vitejs/vite/releases/tag/v4.5.1) [Compare Source](https://togithub.com/vitejs/vite/compare/v4.5.0...v4.5.1) Please refer to [CHANGELOG.md](https://togithub.com/vitejs/vite/blob/v4.5.1/packages/vite/CHANGELOG.md) for details.Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.