CVE-2025-24010

What it actually does

The flaw is a development-server cross-origin access control weakness in Vite. A Vite dev server used default CORS behavior that allowed arbitrary websites to issue requests to the dev server and read responses, and WebSocket upgrade handling did not sufficiently validate the Origin header. If a developer or user has an affected Vite dev server reachable from their browser, a malicious page can cause that browser to interact with the dev server as a cross-origin client and retrieve files, source code, transformed modules, dependency metadata, HMR/WebSocket data, or other dev-server responses that should only be available to the local development context. This is primarily an information disclosure and unauthorized cross-origin interaction issue affecting development environments rather than production Vite-built static assets.

Why it matters to the business

The main risk is exposure of source code, environment-specific development details, internal API usage patterns, secrets accidentally present in frontend source or dev-served files, and proprietary application logic from developer workstations or shared development hosts. Because Vite is widely used in modern frontend development, the issue can affect many engineering teams even when production systems are not directly vulnerable. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association provided, so urgency should be risk-based: prioritize internet-exposed, shared, remote, containerized, or cloud-hosted dev servers and developer environments handling sensitive code or credentials.

How an attack unfolds

An attacker hosts or compromises a website that contains JavaScript designed to probe common Vite development-server locations such as localhost or private-network addresses. When a developer visits that page while running an affected Vite dev server, the malicious page sends cross-origin HTTP requests to the dev server and, where useful, opens a WebSocket connection to the HMR endpoint. Because affected versions allowed broad CORS access and did not adequately reject untrusted WebSocket Origin values, the browser permits the malicious page to read responses that should have been restricted to the trusted development origin. The attacker can then enumerate accessible routes and Vite-specific endpoints, retrieve JavaScript modules or files served through the dev server, inspect build/dependency metadata, and exfiltrate the collected data to attacker-controlled infrastructure. Direct network access to the dev server increases risk, but the browser-based attack path is especially relevant because it can abuse a developer’s browser as a bridge to localhost or private development services.

How to fix it

Upgrade Vite to a version containing the fix. For source builds of vitejs/vite, ensure the code includes commit a55f8ba3e43108de340610d4d021dcd926be5876 or a later release that incorporates it. Because the provided fixed-version data repeats the Git commit rather than package-specific semver versions, validate the exact patched npm package version against the official Vite advisory for the major version in use. As compensating controls, do not expose Vite dev servers to untrusted networks; bind dev servers to localhost rather than 0.0.0.0 unless explicitly required; avoid using permissive CORS in development; restrict access with local firewall rules, VPN, or reverse-proxy authentication for shared dev hosts; and avoid storing secrets in frontend source or files served by the dev server. Treat Vite dev servers as development-only services and do not use them to serve production traffic.

How to confirm the fix worked

Confirm installed Vite versions across repositories and developer images with package-manager lockfiles and dependency inventory, then verify they resolve to a release containing commit a55f8ba3e43108de340610d4d021dcd926be5876 or later. For source deployments, inspect the Git commit history directly. Test exposure by starting the dev server and sending requests with an arbitrary Origin header; patched behavior should not allow untrusted origins to read sensitive dev-server responses and should reject unauthorized WebSocket Origin values. Also verify the dev server is bound only to intended interfaces, preferably 127.0.0.1 or ::1, and that host firewalls prevent access from untrusted networks. From another host on the same network, confirm that common Vite ports are not reachable unless explicitly intended and protected.

Typical attack path

1. Attacker prepares a malicious web page containing JavaScript that targets common Vite dev-server ports and paths.
2. A developer with an affected Vite dev server running visits the malicious page or a compromised site embedding the attack script.
3. The page sends cross-origin fetch/XHR requests to the Vite dev server and checks for Vite-specific responses.
4. The page requests source, module, dependency, or filesystem-served resources exposed by the dev server.
5. The page attempts a WebSocket connection to the Vite HMR endpoint using an untrusted Origin header.
6. Affected Vite behavior allows the malicious origin to read HTTP responses or establish unauthorized WebSocket interaction.
7. The malicious page sends retrieved source code, metadata, or other sensitive development artifacts to attacker-controlled infrastructure.

How to detect it

Investigate whether affected Vite dev servers were reachable and whether browsers or remote clients accessed them from unexpected origins. Useful sources include Vite dev-server console output, reverse-proxy logs if the dev server was proxied, endpoint network telemetry, browser history for visits to suspicious sites while the dev server was running, DNS/proxy logs for outbound connections to unknown domains, and EDR telemetry for Node.js processes listening on Vite ports. Look for HTTP requests to Vite-specific paths with non-local or unfamiliar Origin headers, especially followed by large volumes of module or filesystem requests. Look for WebSocket upgrade requests to Vite HMR endpoints where the Origin header is not the legitimate development application origin. On endpoints, identify Node.js/Vite processes bound to 0.0.0.0 or externally reachable interfaces, and correlate their runtime windows with suspicious browser activity. If source code or secrets may have been exposed, rotate credentials that were present in dev-served files or frontend environment files and review external access logs for follow-on use.

• Origin: http://localhost
• Origin: http://127.0.0.1
• Origin: https://localhost
• Access-Control-Allow-Origin: *
• /@vite/client
• /@fs/
• /node_modules/.vite/
• Sec-WebSocket-Protocol: vite-hmr
• Upgrade: websocket
• vite-hmr
• vite --host 0.0.0.0
• vite --host
• VITE v
• Local: http://localhost:5173/
• Network: http://0.0.0.0:5173/
• LISTEN 0.0.0.0:5173
• LISTEN :::5173

What your security team should do

• Inventory Vite usage in source repositories, development containers, CI images, and shared development environments.
• Upgrade affected Vite installations to a patched release that includes commit a55f8ba3e43108de340610d4d021dcd926be5876 or later.
• Prioritize remediation for dev servers bound to 0.0.0.0, exposed over remote development tunnels, running on shared hosts, or reachable from corporate or cloud networks.
• Enforce secure development-server defaults: localhost binding, no permissive CORS unless justified, and authenticated access for shared remote development workflows.
• Review frontend repositories for secrets or sensitive internal details that may have been exposed through dev-server access.
• Hunt proxy, endpoint, browser, and dev-server logs for unexpected Origin headers, unusual requests to Vite-specific endpoints, and outbound exfiltration following visits to suspicious websites.
• Educate developers that local development servers can be targeted through the browser and should not be left running unnecessarily.
• Add dependency and configuration checks to CI to flag vulnerable Vite versions and risky dev-server host/CORS settings.