Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

GHSA-g4jq-h2w9-997c vite

Fix: lukeed/sirv@f0113f3

GHSA-g4jq-h2w9-997c 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

Also known asCVE-2025-58751
Published
Sep 9, 2025
Updated
Sep 10, 2026
Affected
4 pkgs
Patched
4 / 4
Exploits
None indexed
Exploitation data as of Sep 18, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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-g4jq-h2w9-997c.

EPSS Exploitation Probability

via FIRST.org ↗
1.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs67th percentile — riskier than 67% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

4 pkgs affected

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.

7Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream
vitenpm
163.8Mdownloads / week

Description

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:

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

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
📦npmvite7.1.0&&< 7.1.57.1.5npm install vite@7.1.5
📦npmvite7.0.0&&< 7.0.77.0.7npm install vite@7.0.7
📦npmvite6.0.0&&< 6.3.66.3.6npm install vite@6.3.6
📦npmviteall versions5.4.20npm install vite@5.4.20

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update vite to 7.1.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g4jq-h2w9-997c is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-g4jq-h2w9-997c can be triaged on real exposure rather than presence alone.

Tailored to GHSA-g4jq-h2w9-997c. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

How to detect GHSA-g4jq-h2w9-997c

A community-maintained Nuclei template exists for this CVE. You can scan for it directly:

nuclei -id ghsa-g4jq-h2w9-997c -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.

Frequently Asked Questions

### 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.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - uses [the public directory feature](https://vite.dev/guide/assets.html#the-public-directory) (enabled by default) - a symlink exists in the public directory ### Details The [servePublicMiddleware](https://github.com/vitejs/vite/blob/9719497a
O3 Security · Impact-Aware SCA

Is GHSA-g4jq-h2w9-997c in your dependencies?

O3 Security finds GHSA-g4jq-h2w9-997c across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-g4jq-h2w9-997c: vite | O3 Security