vite 6.2.3
Vite has an server.fs.deny bypass with an invalid request-target
>= 6.2.0, < 6.2.6
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)
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 passed to the user land as well. But for those requests, the value of http.IncomingMessage.url did not contain #.
PoC
npm create vite@latest
cd vite-project/
npm install
npm run dev
send request to read /etc/passwd
curl --request-target /@fs/Users/doggy/Desktop/vite-project/#/../../../../../etc/passwd http://127.0.0.1:5173
Vite allows server.fs.deny to be bypassed with .svg or relative paths
medium severity CVE-2025-31486>= 6.2.0, < 6.2.5
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
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
npm create vite@latest
cd vite-project/
npm install
npm run dev
send request to read etc/passwd
curl 'http://127.0.0.1:5173/etc/passwd?.svg?.wasm?init'
curl 'http://127.0.0.1:5173/@fs/x/x/x/vite-project/?/../../../../../etc/passwd?import&?raw'
Vite has a server.fs.deny bypassed for inline and raw with ?import query
>= 6.2.0, < 6.2.4
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
No license issues detected.
This package version has a license in the source code.
This package version is available.
This package version has not been yanked and is still available for usage.