CVE-2025-58751 — vite
Fix: lukeed/sirv@f0113f3CVE-2025-58751 is a Path Traversal vulnerability in vite. A fix is available for vite — see the affected versions and patch details below.
Vite middleware may serve files starting with the same name with the public directory
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 CVE-2025-58751.
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
Files starting with the same name with the public directory were served bypassing the server.fs settings.
Impact
Only apps that match the following conditions are affected:
- explicitly exposes the Vite dev server to the network (using --host or
server.hostconfig option) - uses the public directory feature (enabled by default)
- a symlink exists in the public directory
Details
The servePublicMiddleware function is in charge of serving public files from the server. It returns the viteServePublicMiddleware function which runs the needed tests and serves the page. The viteServePublicMiddleware function checks if the publicFiles variable is defined, and then uses it to determine if the requested page is public. In the case that the publicFiles is undefined, the code will treat the requested page as a public page, and go on with the serving function. publicFiles may be undefined if there is a symbolic link anywhere inside the public directory. In that case, every requested page will be passed to the public serving function. The serving function is based on the sirv library. Vite patches the library to add the possibility to test loading access to pages, but when the public page middleware disables this functionality since public pages are meant to be available always, regardless of whether they are in the allow or deny list.
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).
PoC
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.
Related links
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | vite | ≥ 7.1.0&&< 7.1.5 | 7.1.5npm install vite@7.1.5 |
| 📦npm | vite | ≥ 7.0.0&&< 7.0.7 | 7.0.7npm install vite@7.0.7 |
| 📦npm | vite | ≥ 6.0.0&&< 6.3.6 | 6.3.6npm install vite@6.3.6 |
| 📦npm | vite | all versions | 5.4.20npm install vite@5.4.20 |
Affected Products
vitevitejsDetection & 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 7.1.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-58751 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.
How to detect CVE-2025-58751
A community-maintained Nuclei template exists for this CVE. You can scan for it directly:
nuclei -id cve-2025-58751 -u https://target- Template
- Vite Dev Server - Path Traversal
- Severity
- low
- Impact
- Attackers can access unauthorized files bypassing filesystem restrictions, potentially exposing sensitive data.
- Remediation
- Update to versions 7.1.5, 7.0.7, 6.3.6, or 5.4.20 or later.
Template by ProjectDiscovery nuclei-templates (wn147), MIT licensed. View the full template. Scan only systems you are authorised to test.
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.
Red Hat Customers should be aware that the underlying vulnerability originates in the sirv package, which is responsible for serving static files. Vite uses sirv internally to serve content during development, which means projects using Vite were also exposed to the issue. While sirv is technically the component…
* Avoid exposing the Vite dev server (--host / server.host) to untrusted networks. * Do not allow symlinks inside the public directory that reference files outside of it.Source: Red Hat security advisory for CVE-2025-58751 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2025-58751 in your dependencies?
Find it across npm, including transitive dependencies.