Vite: Files outside `server.fs.allow` could be served when project paths match system paths on non-Windows machine
Published 21 Oct 2026 · Updated 21 Oct 2026
Affected packages
- Affected
- >=8.3.0 <8.3.3
- Fixed in
- 8.3.3
npm install vite@8.3.3- Affected
- >=8.2.0 <8.2.4
- Fixed in
- 8.2.4
npm install vite@8.2.4- Affected
- >=8.0.0 <8.1.6
- Fixed in
- 8.1.6
npm install vite@8.1.6- Affected
- >=7.0.0 <7.3.7
- Fixed in
- 7.3.7
npm install vite@7.3.7- Affected
- <6.4.4
- Fixed in
- 6.4.4
npm install vite@6.4.4- Affected
- <1.1.0
- Fixed in
- 1.1.0
npm install vite-plus@1.1.0Details
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. For example, referencing <project-root>/etc/hosts could make Vite return the host's /etc/hosts file.
Impact
Only apps that meet all of the following conditions are affected:
- explicitly expose the Vite dev server to the network (using
--hostor the `server.host` option) - contain an imported file whose root-relative browser URL is also the absolute path of a readable file on the host
- The sensitive file is not matched by `server.fs.deny`
- the dev server is not running on Windows
Details
When Vite analyzes an in-root import, it rewrites the resolved module ID to a browser URL such as /etc/hostname. In affected versions, Vite converts that URL with fsPathFromUrl and adds the result to safeModulePaths. Because fsPathFromUrl ensures a leading slash without resolving the URL against the project root, the project URL /etc/hostname is recorded as if it were the absolute filesystem path /etc/hostname.
For a later request to /@fs/etc/hostname, the raw-filesystem middleware interprets /etc/hostname as an absolute path. The access check applies server.fs.deny, then accepts paths present in safeModulePaths before checking server.fs.allow. As a result, the request can return the host file instead of the project file that originally populated safeModulePaths.
PoC
The following example requires Linux with a readable /etc/hostname:
$ mkdir vite-safe-module-path-poc $ cd vite-safe-module-path-poc $ npm init -y $ npm install vite@8.3.1 $ mkdir -p etc $ echo 'PROJECT-DECOY\n' > etc/hostname $ echo 'import "./etc/hostname"\n' > main.js $ npx vite --host 127.0.0.1
In another terminal:
$ curl -o /dev/null -s -w '%{http_code}\n' http://127.0.0.1:5173/main.js
200
$ curl -sS -o response -w '%{http_code}\n' http://127.0.0.1:5173/@fs/etc/hostname
200
$ cmp -s response /etc/hostname && echo 'response matches host file'
response matches host fileIs GHSA-rq7h-c2jc-7f22 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
- Linkgithub.com/vitejs/vite/security/advisories/GHSA-rq7h-c2jc-7f22
- Advisorynvd.nist.gov/vuln/detail/CVE-2026-112946
- Linkgithub.com/vitejs/vite/pull/23656
- Linkgithub.com/vitejs/vite/commit/170b92791421bcd484f7325936d989a82d6bd4aa
- Linkgithub.com/vitejs/vite/commit/45c0e3392a298626955a0ab93a8e51232daac721
- Linkgithub.com/vitejs/vite/commit/c3e06f92e969952466b4e2f5801e85e1e00cd905
- Linkgithub.com/vitejs/vite/commit/e570d8d016096b5f8f6f09808376ca6cf73f27d0
- Linkgithub.com/vitejs/vite/commit/f0d76c7da13d5e794807b82f0b86c1931a8438e3
- Packagegithub.com/vitejs/vite
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.