VITE · GHSA-p4f5-76q4-ffq7 · Package
FIX → 8.3.7 · 7.3.8 · 6.4.6 · 1.5.1 +2
A crafted HTTP request to the Vite dev server injects code into a virtual module, which the server then evaluates. An attacker can run code on the machine and read files outside the allowed serving list.
first public Nov 10, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Only projects that run the Vite dev server reachable from the network, either with the --host flag or with server.host set in the config. Dev servers bound to localhost only, and production builds, are not exposed by this flaw. Teams should patch any developer machine or shared dev environment that exposes the server.
Not affected if default-config, localhost-only-dev-server, production-build-only
Who cares dev-server, npm, vite, vite-plus
By sending an HTTP request to the dev server, a arbitrary code execution was possible.
Only apps that match the following condition are affected:
--host or server.host config option)Vite's resolver plugin has __vite-browser-external:<suffix> virtual module and __vite-optional-peer-dep:<suffix> virtual module. These modules embedded the module ID, which is derived from the URL, without escaping. The <suffix> can be any value, so any code was able to be injected in those modules.
Since Vite trusts the module code, there was two problems with this injection.
First, the modules referenced by a module are allowed for the server.fs check. For example, if the attacker injects import '/path/to/some-secret-file.txt', /path/to/some-secret-file.txt can be fetched.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
npm ls vite in the project and compare the installed version with the fixed versions below.--host or has server.host set in the Vite config, since only exposed servers are affected.Upgrade to 8.3.7 · 7.3.8 · 6.4.6 · 1.5.1 +2
vite 8.3.7 for the 8.3.x linevite 8.2.5 for the 8.2.x linevite 8.1.7 for the 8.1.x linevite 7.3.8 for the 7.x linevite 6.4.6 for the 4.x to 6.x rangevite-plus 1.5.1 for versions up to 1.5.0Second, Vite uses eval to extract the value in the module code for new Worker and import.meta.glob. By using that functionality, the attacker can make Vite evaluate the injected code on the server. Vite prevents some module / global variables like exports, require to avoid bugs, but because this is not a security boundary, there's a bypass like globalThis.process.getBuiltinModule.
printf 'CANARY-SECRET-not-valid-js\n' > /tmp/decoy-secret.txt # outside the project
vite
/tmp/decoy-secret.txt stands in for any sensitive file outside the allow list.
GET /@fs/tmp/decoy-secret.txt returns 403 Restricted ("outside of Vite serving allow list").GET /@id/__vite-browser-external:`);}});
import '/@fs/tmp/decoy-secret.txt';
var z=new Proxy({}, {get(_, key) {throw new Error(`?import
/tmp/decoy-secret.txt into the module graph.GET /@fs/tmp/decoy-secret.txt returns the content in the body (CANARY-SECRET-not-valid-js).The vulnerable code in v8 lives in the Rolldown binary. The code is only meant to be used by Vite and thus the report is not linked to Rolldown. Vite 8.3.7 and Vite 8.2.5 relies on the fix in Rolldown 1.2.17. Vite 8.1.7 relies on the fix in Rolldown 1.1.7.