Vite: Files outside `server.fs.allow` could be served when project paths match system paths on non-Windows machineGHSA-rq7h-c2jc-7f22
Fix: vitejs/vite#23656GHSA-rq7h-c2jc-7f22 is a Path Traversal vulnerability in vite. A fix is available for vite — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-rq7h-c2jc-7f22.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
vitenpmDescription
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 theserver.hostoption) - 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 [email protected]
$ 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 file
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | vite | ≥ 8.3.0&&< 8.3.3 | 8.3.3npm install vite@8.3.3 |
| 📦npm | vite | ≥ 8.2.0&&< 8.2.4 | 8.2.4npm install vite@8.2.4 |
| 📦npm | vite | ≥ 8.0.0&&< 8.1.6 | 8.1.6npm install vite@8.1.6 |
| 📦npm | vite | ≥ 7.0.0&&< 7.3.7 | 7.3.7npm install vite@7.3.7 |
| 📦npm | vite | all versions | 6.4.4npm install vite@6.4.4 |
| 📦npm | vite-plus | all versions | 1.1.0npm install vite-plus@1.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vite, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update vite to 8.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rq7h-c2jc-7f22 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated with a Low severity because it solely affects the development server under non-default, highly specific conditions rather than production application deployments. In Red Hat products, Vite is primarily utilized as a build-time asset bundler where the development web server is not exposed…
Avoid exposing the Vite development server to external networks and restrict access to sensitive host paths. 1. Bind the development server to localhost: Ensure the Vite development server does not listen on public interfaces by omitting the `--host` CLI flag or setting the host explicitly in `vite.config.js`: ```javascript export default { server: { host: '127.0.0.1' } }; ``` 2. Deny sensitive filesystem paths: Configure `server.fs.deny` in `vite.config.js` to block requests for sensitive system files and directories: ```javascript export default { server: { fs: { deny: ['/etc/**', '/root/**', '/home/**'] } } }; ``` 3. Restrict network access via firewall: If the server must run on a…Source: Red Hat security advisory for GHSA-rq7h-c2jc-7f22 (CC BY 4.0)
Frequently Asked Questions
Is GHSA-rq7h-c2jc-7f22 in your dependencies?
Find it across npm, including transitive dependencies.