Vite's development server versions >=2.5.1 and <6.0.9 have a security flaw where the default CORS configuration allows any origin to fetch resources, and the WebSocket server does not validate the Origin header, enabling Cross-Site WebSocket Hijacking (CSWSH). This combination permits malicious websites to send arbitrary requests to the dev server and read responses, including local-only servers not exposed to the network. The vulnerability arises from three main issues: permissive CORS defaulting to Access-Control-Allow-Origin: *, lack of Origin header validation on WebSocket connections, and lack of Host header validation on HTTP requests. The vendor has released patches addressing these issues and introduced configuration options such as server.cors.origin and server.allowedHosts to restrict access. Users employing backend integration, reverse proxies, or accessing the server via non-localhost domains must adjust configurations accordingly. No mitigations exist for WebSocket Origin validation except upgrading. Using Chrome 94+ or HTTPS helps mitigate Host header issues.

The vulnerability allows attackers to bypass same-origin policy restrictions on the Vite development server, enabling them to fetch and read resources served by the dev server from any origin. This can lead to unauthorized disclosure of development files and information. Additionally, the lack of Origin validation on WebSocket connections enables attackers to hijack WebSocket sessions, potentially reading and writing messages related to hot module replacement and error reporting. The impact is limited to confidentiality as integrity and availability are not affected. The vulnerability affects even local-only dev servers that are not exposed to the network, increasing the risk for developers running Vite locally.

A fix is available in Vite versions 6.0.9 and later. Users should upgrade to a patched version to fully mitigate the vulnerability. For those unable to upgrade immediately, mitigations include setting server.cors to false or restricting server.cors.origin to trusted origins to address permissive CORS settings. When using backend integration, configure server.cors.origin explicitly to trusted backend origins. If using a reverse proxy or accessing the dev server via domains other than localhost or *.localhost, add those hostnames to server.allowedHosts. For WebSocket Origin header validation issues, no mitigations exist other than upgrading. Using Chrome 94+ or HTTPS for the development server helps mitigate Host header validation issues. Users relying on plugins or frameworks that connect to the WebSocket server independently may need to adjust plugin code or use the legacy.skipWebSocketTokenCheck option with awareness of security implications.