CVE-2026-39363

What it actually does

This vulnerability allows unauthenticated remote file read through the Vite development server WebSocket interface. Affected Vite versions expose a custom WebSocket event, vite:invoke, that can call fetchModule. When an attacker can establish a WebSocket connection without an Origin header, they can request file:// URLs combined with ?raw or ?inline and receive local file contents serialized as JavaScript module output, such as export default "...". The normal HTTP-side file access controls, including restrictions such as server.fs.allow, are bypassed because the vulnerable WebSocket execution path does not enforce the same filesystem allowlist checks. The flaw 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 development server is reachable by an attacker, sensitive files on the host can be exposed without authentication. This may include source code, application configuration, environment files, credentials, API keys, private certificates, build secrets, or other local files accessible to the Vite process. While Vite dev servers are not intended to be internet-facing, accidental exposure in developer workstations, CI environments, preview environments, containers, or cloud development platforms can turn this into a high-impact secret disclosure issue. The exploit is reported as weaponized, so exposed instances should be treated as urgent even though the vulnerability is not currently listed in CISA KEV and has a relatively low EPSS score.

How an attack unfolds

An attacker first identifies a reachable Vite development server that accepts WebSocket upgrade connections. They then establish a WebSocket session in a way that omits the Origin header or otherwise reaches the vulnerable no-Origin path. After the connection is accepted, the attacker sends a crafted vite:invoke message targeting fetchModule. Instead of requesting a normal application module, the attacker supplies a file:// URL pointing to a local filesystem path and appends ?raw or ?inline. The vulnerable server resolves and reads the file through the WebSocket module-fetch path and returns the contents as a JavaScript string. The attacker repeats this process for high-value paths such as environment files, package metadata, source files, SSH keys, cloud credential files, or application configuration files.

How to fix it

Upgrade Vite to a fixed version: 6.4.2 or later for the 6.x line, 7.3.2 or later for the 7.x line, or 8.0.5 or later for the 8.x line. Because Vite is commonly included as a development dependency through frontend frameworks and build tooling, update both direct and transitive package versions and regenerate lockfiles. Do not expose Vite development servers to untrusted networks; bind dev servers to localhost where possible, restrict access with firewall rules or VPN controls, and avoid running Vite dev servers in internet-accessible preview or CI environments unless they are explicitly protected. As compensating controls, block unauthenticated WebSocket access to Vite dev-server endpoints at reverse proxies, require valid Origin headers where feasible, and prevent requests containing file:// module specifiers. Review whether secrets were stored on hosts where vulnerable Vite dev servers were reachable and rotate exposed credentials if exploitation cannot be ruled out.

How to confirm the fix worked

Confirm that installed Vite versions are not in the vulnerable ranges: 6.0.0 through 6.4.1, 7.0.0 through 7.3.1, or 8.0.0 through 8.0.4. Validate package manager state using package.json and lockfiles such as package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, or bun.lockb, and verify the resolved Vite version in node_modules where applicable. Confirm that no Vite dev server is reachable from untrusted networks by scanning exposed interfaces and checking listening services. Where safe and authorized, test that WebSocket requests without an Origin header are rejected or that crafted vite:invoke fetchModule requests using file:// with ?raw or ?inline do not return local file contents. Also verify that reverse proxy, firewall, and development environment configurations restrict access to Vite dev-server ports.

Typical attack path

1. Discover an exposed Vite development server through scanning, application fingerprinting, leaked preview URLs, or developer tooling exposure.
2. Confirm that the server accepts WebSocket connections associated with Vite dev-server/HMR behavior.
3. Open a WebSocket connection without an Origin header or through a client/proxy configuration that suppresses Origin.
4. Send a crafted vite:invoke WebSocket event that calls fetchModule.
5. Use a file:// URL with ?raw or ?inline to request a local file from the server filesystem.
6. Receive the file contents in the WebSocket response as a JavaScript module string.
7. Repeat requests against likely sensitive paths and use exposed secrets for follow-on access.

How to detect it

Standard web access logs may show only WebSocket upgrade requests and often will not capture the malicious WebSocket payload, so detection should combine network telemetry, reverse proxy logs, endpoint logs, and any available WebSocket frame capture. Review logs for WebSocket upgrade requests to Vite dev-server ports, especially requests without an Origin header, from unexpected external IP addresses, or with unusual user agents. If proxy, WAF, packet capture, or application instrumentation records WebSocket frames, search for vite:invoke messages that reference fetchModule and contain file:// paths with ?raw or ?inline. On endpoints, look for Vite dev-server processes bound to non-loopback interfaces and correlate their runtime with suspicious inbound connections. Investigate whether likely secret files were accessed or exfiltrated, including .env files, configuration files, SSH keys, cloud credential files, package manager tokens, and source files. Because exploitation is weaponized, any exposed vulnerable instance with suspicious no-Origin WebSocket activity should be treated as potential compromise and followed by secret rotation and host review.

• vite:invoke
• fetchModule
• file://
• ?raw
• ?inline
• export default "
• Connection: Upgrade
• Upgrade: websocket
• Sec-WebSocket-Key:
• Sec-WebSocket-Version: 13
• Origin: null
• /node_modules/.vite/
• /.env
• /.env.local
• /.env.development
• /.env.production
• /.npmrc
• /.yarnrc.yml
• /.pnpmrc
• /id_rsa
• /id_ed25519
• /.ssh/id_rsa
• /.ssh/id_ed25519
• /.aws/credentials
• /.config/gcloud/application_default_credentials.json
• VITE_

What your security team should do

• Prioritize remediation for any Vite dev server reachable from the internet, shared networks, CI/CD runners, cloud workspaces, or preview environments.
• Upgrade all affected Vite installations to 6.4.2, 7.3.2, 8.0.5, or later, including transitive framework-managed installations.
• Inventory frontend repositories and developer images for vulnerable Vite versions using software composition analysis and lockfile searches.
• Restrict Vite dev servers to localhost or trusted networks only; do not rely on Vite dev-server access controls as a security boundary.
• Add network or proxy controls to deny unauthenticated WebSocket traffic to Vite development servers from untrusted sources.
• Search logs and packet captures for WebSocket messages containing vite:invoke, fetchModule, file://, ?raw, or ?inline.
• If exposure is confirmed or cannot be ruled out, investigate for sensitive file reads and rotate secrets that may have resided on affected hosts.
• Educate development teams that Vite dev servers are development-only services and should not be exposed directly to the internet.