| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| vite | npm | >= 7.1.0, <= 7.1.4 | 7.1.5 |
| vite | npm | >= 7.0.0, <= 7.0.6 | 7.0.7 |
| vite | npm | >= 6.0.0, <= 6.3.5 | 6.3.6 |
| vite | npm | <= 5.4.19 | 5.4.20 |
The vulnerability is a path traversal issue originating in the sirv library, a dependency of Vite. The core of the issue lies in the viaLocal function within sirv, which fails to properly sanitize user-provided paths. It uses a startsWith check to ensure that the resolved file path is within the designated public directory. However, because it doesn't enforce a trailing slash on the directory path, it's possible to craft a path using ../ that resolves outside the public directory but still passes the startsWith check.
Vite becomes vulnerable by its use of sirv within its servePublicMiddleware. Under specific conditions, namely when a symbolic link exists within the project's public directory, a function in Vite (resolvePublicFiles) returns undefined. This causes the middleware returned by servePublicMiddleware to pass all incoming requests to the vulnerable sirv instance, rather than just requests for files known to be in the public directory. This effectively opens up the path traversal vulnerability in sirv to be exploited through the Vite development server.
The patch for sirv (commit f0113f3f8266328d804ee808f763a3c11f8997eb) addresses the root cause by ensuring the directory path passed to viaLocal always has a trailing slash, making the startsWith check secure against traversal attacks. The patches for Vite consist of updating the sirv dependency to a patched version.
In the case of public pages, the serving function is provided with the path to the public directory as a root directory. The code of the sirv library uses the join function to get the full path to the requested file. For example, if the public directory is "/www/public", and the requested file is "myfile", the code will join them to the string "/www/public/myfile". The code will then pass this string to the normalize function. Afterwards, the code will use the string's startsWith function to determine whether the created path is within the given directory or not. Only if it is, it will be served.
Since sirv trims the trailing slash of the public directory, the string's startsWith function may return true even if the created path is not within the public directory. For example, if the server's root is at "/www", and the public directory is at "/www/p", if the created path will be "/www/private.txt", the startsWith function will still return true, because the string "/www/private.txt" starts with "/www/p". To achieve this, the attacker will use ".." to ask for the file "../private.txt". The code will then join it to the "/www/p" string, and will receive "/www/p/../private.txt". Then, the normalize function will return "/www/private.txt", which will then be passed to the startsWith function, which will return true, and the processing of the page will continue without checking the deny list (since this is the public directory middleware which doesn't check that).
Execute the following shell commands:
npm create vite@latest
cd vite-project/
mkdir p
cd p
ln -s a b
cd ..
echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({publicDir: path.resolve(__dirname, "p/"), server: {fs: {deny: [path.resolve(__dirname, "private.txt")]}}})' > vite.config.js
echo "secret" > private.txt
npm install
npm run dev
Then, in a different shell, run the following command:
curl -v --path-as-is 'http://localhost:5173/private.txt'
You will receive a 403 HTTP Response, because private.txt is denied.
Now in the same shell run the following command:
curl -v --path-as-is 'http://localhost:5173/../private.txt'
You will receive the contents of private.txt.
Ongoing coverage of React2Shell