Vite allowed any websites to send any requests to the development server and read the response due to default CORS settings and lack of validation on the Origin header for WebSocket connections.
[!WARNING] This vulnerability even applies to users that only run the Vite dev server on the local machine and does not expose the dev server to the network.
Users that does not match either of the following conditions should be able to upgrade to a newer version of Vite that fixes the vulnerability without any additional configuration.
localhost
or *.localhost
If you are using the backend integration feature and not setting server.origin
, you need to add the origin of the backend server to the server.cors.origin
option. Make sure to set a specific origin rather than *
, otherwise any origin can access your development server.
If you are using a reverse proxy in front of Vite and sending requests to Vite with a hostname other than localhost
or *.localhost
, you need to add the hostname to the new server.allowedHosts
option. For example, if the reverse proxy is sending requests to http://vite:5173
, you need to add vite
to the server.allowedHosts
option.
localhost
or *.localhost
You need to add the hostname to the new server.allowedHosts
option. For example, if you are accessing the development server via http://foo.example.com:8080
, you need to add foo.example.com
to the server.allowedHosts
option.
If you are using a plugin / framework, try upgrading to a newer version of Vite that fixes the vulnerability. If the WebSocket connection appears not to be working, the plugin / framework may have a code that connects to the WebSocket server on their own from the browser.
In that case, you can either:
legacy.skipWebSocketTokenCheck: true
to opt-out the fix for [2] while the plugin / framework is incompatible with the new version of Vite
Set server.cors
to false
or limit server.cors.origin
to trusted origins.
There aren't any mitigations for this.
Use Chrome 94+ or use HTTPS for the development server.
There are three causes that allowed malicious websites to send any requests to the development server:
Vite sets the Access-Control-Allow-Origin
header depending on server.cors
option. The default value was true
which sets Access-Control-Allow-Origin: *
. This allows websites on any origin to fetch
contents served on the development server.
Attack scenario:
http://malicious.example.com
).fetch('http://127.0.0.1:5173/main.js')
request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.http://127.0.0.1:5173/main.js
.Vite starts a WebSocket server to handle HMR and other functionalities. This WebSocket server did not perform validation on the Origin header and was vulnerable to Cross-Site WebSocket Hijacking (CSWSH) attacks. With that attack, an attacker can read and write messages on the WebSocket connection. Vite only sends some information over the WebSocket connection (list of the file paths that changed, the file content where the errored happened, etc.), but plugins can send arbitrary messages and may include more sensitive information.
Attack scenario:
http://malicious.example.com
).new WebSocket('http://127.0.0.1:5173', 'vite-hmr')
by JS in that malicious web page.Unless server.https
is set, Vite starts the development server on HTTP. Non-HTTPS servers are vulnerable to DNS rebinding attacks without validation on the Host header. But Vite did not perform validation on the Host header. By exploiting this vulnerability, an attacker can send arbitrary requests to the development server bypassing the same-origin policy.
http://malicious.example.com:5173
) (HTTPS won't work).fetch('/main.js')
request by JS in that malicious web page.http://127.0.0.1:5173/main.js
bypassing the same origin policy.Users with the default server.cors
option may:
server.proxy
may have those functionalities.All users may get the file paths of the files that changed and the file content where the error happened be stolen by malicious websites.
For users that is using a plugin that sends messages over WebSocket, that content may be stolen by malicious websites.
For users that is using a plugin that has a functionality that is triggered by messages over WebSocket, that functionality may be exploited by malicious websites.
Users using HTTP for the development server and using a browser that is not Chrome 94+ may:
server.proxy
may have those functionalities.Chrome 94+ users are not affected for [3], because sending a request to a private network page from public non-HTTPS page is forbidden since Chrome 94.
Safari has a bug that blocks requests to loopback addresses from HTTPS origins. This means when the user is using Safari and Vite is listening on lookback addresses, there's another condition of "the malicious web page is served on HTTP" to make [1] and [2] to work.
I used the react
template which utilizes HMR functionality.
npm create vite@latest my-vue-app-react -- --template react
Then on a malicious server, serve the following POC html:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>vite CSWSH</title>
</head>
<body>
<div id="logs"></div>
<script>
const div = document.querySelectorAll('#logs')[0];
const ws = new WebSocket('ws://localhost:5173','vite-hmr');
ws.onmessage = event => {
const logLine = document.createElement('p');
logLine.innerHTML = event.data;
div.append(logLine);
};
</script>
</body>
</html>
Kick off Vite
npm run dev
Load the development server (open http://localhost:5173/
) as well as the malicious page in the browser.
src/App.jsx
file and intentionally place a syntax errorHere's a video demonstrating the POC:
https://github.com/user-attachments/assets/a4ad05cd-0b34-461c-9ff6-d7c8663d6961
{ "nvd_published_at": "2025-01-20T16:15:28Z", "cwe_ids": [ "CWE-1385", "CWE-346", "CWE-350" ], "severity": "MODERATE", "github_reviewed": true, "github_reviewed_at": "2025-01-21T19:52:55Z" }