CVE-2026-39365

What it actually does

The Vite development server path handling for optimized dependency source-map requests can resolve URL paths containing directory traversal sequences before enforcing the intended server.fs.strict filesystem allow list. An unauthenticated network attacker who can reach the dev server can request specially crafted .map URLs that traverse outside the project root and cause the server to read arbitrary source-map files outside the configured allow list, as long as the target file is valid source map JSON. The impact is confidentiality-only: exposed source maps can reveal source code structure, local file paths, comments, dependency internals, and occasionally embedded secrets or sensitive implementation details. The issue affects Vite 6.0.0 through versions before 6.4.2, 7.3.2, and 8.0.5.

Why it matters to the business

If a Vite dev server is exposed to untrusted networks, attackers may be able to retrieve source-map files outside the application directory, potentially disclosing proprietary code details, development paths, dependency information, or sensitive values accidentally included in source maps. The CVSS score is moderate and EPSS is currently low, but exploit maturity is listed as weaponized, so internet-facing or shared-network development servers should be treated as higher priority even though the issue is not currently in the CISA KEV catalog and is not known to be ransomware-associated.

How an attack unfolds

An attacker first identifies a reachable Vite development server, usually by probing common development ports or recognizing Vite-specific responses and assets. They then send crafted HTTP requests for optimized dependency .map files where the URL contains ../ traversal segments, including encoded variants, to influence the server-side path resolution. In vulnerable versions, the dev server resolves the path and calls readFile without correctly rejecting traversal outside the configured filesystem allow list. If the resolved target is a valid source map JSON file, the server returns it to the attacker. The attacker reviews returned source maps for source paths, embedded sources, comments, dependency versions, internal package names, credentials mistakenly embedded in maps, API endpoints, or other information that can support later intrusion or intellectual-property theft.

How to fix it

Upgrade Vite to a fixed release: 6.x users should upgrade to 6.4.2 or later, 7.x users to 7.3.2 or later, and 8.x users to 8.0.5 or later. If package manifests allow broad version ranges, refresh lockfiles and rebuild containers or development images so the fixed Vite version is actually installed. Remove public exposure of Vite dev servers; bind them to localhost where possible and place any required remote development access behind VPN, SSH tunneling, or authenticated access controls. Do not rely on server.fs.strict as the only protection until patched. As defense in depth, restrict inbound access to common Vite development ports, disable unnecessary dev servers in shared or production-like environments, and review generated source maps for embedded secrets or sensitive sourceContent.

How to confirm the fix worked

Confirm the installed Vite version with package-manager inventory commands such as npm ls vite, pnpm why vite, yarn why vite, or by inspecting lockfiles and built development images. Verify that all affected major lines are at or above 6.4.2, 7.3.2, or 8.0.5. From an untrusted network perspective, confirm that Vite dev server ports are not reachable unless intentionally protected. For functional validation, create a harmless valid source-map JSON file outside a test project root and attempt a traversal-based .map request against a non-production dev server; fixed versions should deny or fail the request rather than return the file content. Also review reverse-proxy and access logs for historical traversal attempts against .map resources and confirm that no successful 200 responses returned source-map JSON from paths outside the intended project root.

Typical attack path

1. Discover a reachable Vite development server on a network-accessible host or development port.
2. Confirm the server is running an affected Vite version or behaves like a vulnerable Vite dev server.
3. Craft .map requests for optimized dependencies that include ../ traversal segments or encoded traversal variants.
4. Send the requests and look for HTTP 200 responses with source-map JSON content.
5. Extract source paths, sourceContent, comments, dependency metadata, and any accidentally embedded sensitive values from the returned maps.
6. Use the disclosed information to improve follow-on attacks, target internal endpoints, identify vulnerable dependencies, or steal proprietary implementation details.

How to detect it

Review web server, reverse-proxy, WAF, EDR network, and Vite dev server logs for requests to .map resources that contain directory traversal sequences. Focus on successful HTTP 200 responses, unusually large JSON responses, content types associated with JavaScript or JSON, and requests targeting optimized dependency paths. Search for both plain and encoded traversal forms such as ../, ..%2f, %2e%2e%2f, %252e%252e%252f, and backslash variants. Correlate suspicious requests with source IPs performing port scanning, repeated probing of development ports, or enumeration of node_modules/.vite/deps assets. For forensic review, identify whether returned source maps included sourcesContent, local absolute paths, internal package names, API routes, credentials, or environment-specific values. If exploitation is suspected, preserve access logs, proxy logs, dev server console output, container logs, and any network captures; then rotate secrets that may have appeared in source maps and assess follow-on access from the same source addresses.

• GET /node_modules/.vite/deps/../
• GET /node_modules/.vite/deps/%2e%2e%2f
• GET /node_modules/.vite/deps/..%2f
• GET /node_modules/.vite/deps/%252e%252e%252f
• GET /node_modules/.vite/deps/..%5c
• GET /node_modules/.vite/deps/%2e%2e%5c
• .map?
• ../*.map
• %2e%2e%2f*.map
• ..%2f*.map
• %252e%252e%252f*.map
• /node_modules/.vite/deps/
• "sourcesContent"
• "version":3
• "sourceRoot"

What your security team should do

• Immediately inventory Vite usage across repositories, developer workstations, CI images, containers, and remote development environments.
• Prioritize patching any Vite dev server reachable from the internet, shared corporate networks, partner networks, or remote development platforms.
• Upgrade to Vite 6.4.2, 7.3.2, 8.0.5, or later depending on the major version in use, and verify lockfiles and runtime images reflect the fixed version.
• Restrict Vite dev servers to localhost or authenticated private access; block unauthenticated inbound access to development ports at network and host firewalls.
• Search HTTP logs for .map requests containing traversal sequences, including URL-encoded variants, especially where responses were HTTP 200 with JSON content.
• Review exposed source maps for secrets, tokens, internal URLs, sourceContent, or proprietary code and rotate any credentials found.
• Add SIEM detections for path traversal attempts against Vite optimized dependency source-map paths.
• Because exploit maturity is weaponized, treat confirmed exposure with successful suspicious .map retrievals as a potential information disclosure incident even though the CVE is not currently KEV-listed.