MediumGHSA-4w7w-66w2-5vf9CVE-2026-39365

Vite Vulnerable to Path Traversal in Optimized Deps `.map` Handling

Published 6 Apr 2026 · Updated 10 Sept 2026

Affected packages

vitenpm
Affected
>=8.0.0 <8.0.5
Fixed in
8.0.5
Update to the fixed version for your release line, for example:npm install vite@8.0.5
vitenpm
Affected
>=7.0.0 <7.3.2
Fixed in
7.3.2
Update to the fixed version for your release line, for example:npm install vite@7.3.2
vitenpm
Affected
<6.4.2
Fixed in
6.4.2
Update to the fixed version for your release line, for example:npm install vite@6.4.2

Details

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)
  • 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` 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

    cat > /tmp/poc.map <<'EOF'
    {"version":3,"file":"x.js","sources":[],"names":[],"mappings":""}
    EOF

2. Start the Vite dev server (example)

    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" />

Is GHSA-4w7w-66w2-5vf9 in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected vite, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.