Vite fixes dev-server WebSocket arbitrary file read

TL;DR — Vite’s dev server can leak arbitrary server files via a WebSocket-only code path that bypasses server.fs.allow, turning an exposed dev server into a direct secret/source disclosure risk.

What happened

Vite is a frontend tooling framework for JavaScript that ships a fast local development server (including an HMR WebSocket endpoint). CVE-2026-39363 describes an arbitrary file read issue in the Vite dev server: if an attacker can connect to the dev server’s WebSocket without an Origin header, they can invoke fetchModule via Vite’s custom WebSocket event vite:invoke and combine a file://... URL with ?raw (or ?inline) to retrieve arbitrary file contents as a JavaScript string (e.g., export default "...").

Critically, the CVE notes that filesystem access controls enforced on the HTTP request path (e.g., server.fs.allow) are not applied to this WebSocket-based execution path.

This is the exact failure mode defenders worry about with dev servers: a “local-only” assumption plus a hidden alternate code path (WebSocket) can bypass controls teams believe are protecting sensitive files.

Who is impacted

• Any deployment running Vite versions >= 6.0.0, < 6.4.2, >= 7.0.0, < 7.3.2, or >= 8.0.0, < 8.0.5.
• Teams using vite-plus versions < 0.1.16.
• Highest-risk environments where a Vite dev server is reachable from untrusted networks (e.g., misconfigured --host exposure, shared office/Wi-Fi networks, exposed CI preview runners), because the issue enables reading arbitrary files from the dev server host.

What to do now

• Follow vendor remediation guidance and apply a patched release.

  "This vulnerability is fixed in 6.4.2, 7.3.2, and 8.0.5."

• Inventory where Vite dev servers might be reachable beyond localhost (developer workstations, ephemeral preview environments, CI runners) and prioritize anything exposed to broader networks.
• Reduce exposure while upgrading:
  • ensure dev servers are not internet-exposed (bind to localhost where feasible)
  • enforce network-layer restrictions (VPN/allowlists) for any shared dev environments
• If exposure is suspected, treat this as a host file disclosure event: review access logs for unexpected WebSocket connections and rotate any credentials that may have been present on disk on the affected host (e.g., env files, service tokens, cloud creds).