Vite has a `server.fs.deny` bypassed for `inline` and `raw` with `?import` query
Published 31 Mar 2025 · Updated 10 Sept 2026
Affected packages
- Affected
- >=6.2.0 <6.2.4
- Fixed in
- 6.2.4
npm install vite@6.2.4- Affected
- >=6.1.0 <6.1.3
- Fixed in
- 6.1.3
npm install vite@6.1.3- Affected
- >=6.0.0 <6.0.13
- Fixed in
- 6.0.13
npm install vite@6.0.13- Affected
- >=5.0.0 <5.4.16
- Fixed in
- 5.4.16
npm install vite@5.4.16- Affected
- <4.5.11
- Fixed in
- 4.5.11
npm install vite@4.5.11Details
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
Is GHSA-4r4m-qw57-chr8 in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected vite, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.