Vite Dev Server WebSocket Bypass Exposes .env Credentials

WebSocket Bypass Circumvents All File Protections

Vite's HMR uses WebSocket, which operates on a separate path from HTTP. HTTP requests pass through server.fs.allow allowlist and server.fs.deny denylist, but WebSocket connections do not.

The vulnerability lies in the vite:invoke custom event. After connecting to the WebSocket, an attacker sends a message:

{ "type": "custom", "event": "vite:invoke", "data": { "name": "fetchModule", "id": "send:1", "data": ["file:///etc/passwd?raw"] } }

fetchModule

is registered as a remotely callable method via vite:invoke. It takes a file:// path with a ?raw suffix, reads the file content, wraps it as export default "...", and returns it.

Thus .env, SSH private keys, /etc/passwd, and any file accessible to the dev server process can be read if the dev server is exposed publicly.

Why WebSocket Connections Require No Authentication

Vite's shouldHandle function has a design: if the request includes an Origin header (browser-sent), it checks for a token; if not (non-browser), it allows the request.

if (req.headers.origin) { // browser request: requires token
  return hasValidToken(config, parsedUrl);
}
// non-browser request: passwordless allow
return true;

The intent was to allow Node processes and CLI tools to freely connect to HMR. However, attackers using curl or scripts can initiate WebSocket connections without an Origin header, becoming "trusted internal components."

Affected Versions

Fixes:

April batch:
6.0.0 — 6.4.1 → 6.4.2
7.0.0 — 7.3.1 → 7.3.2
8.0.0 — 8.0.4 → 8.0.5

October batch: upgrade to latest

npm install vite@latest

server.fs.deny Is Not a Defense

server.fs.deny

has been bypassed three times in six months: WebSocket bypass, query parameter bypass, Windows path bypass.

This is not a misconfiguration issue; the dev server's security model assumes it is not exposed to the public internet. Once that assumption is broken, all filesystem protections are merely suggestions, not enforcement.

The dev server is designed for local developer use only—it has no authentication, no isolation, no auditing. Exposing it to the public internet is equivalent to placing a machine with a file-read API on a public street.