Vite dev server security: localhost vs --host.

Vite dev server security came back into focus on October 6, 2026, when the Vite team published three advisories and patched five release lines in one morning. All three bugs live in the development server, not in production builds. That sounds reassuring until you count how many headless storefront teams run that dev server with --host so a phone, a tablet or a colleague on the same network can see the work.

What changed in Vite on October 6, 2026

Vite shipped 8.3.3, 8.2.4, 8.1.6, 7.3.7 and 6.4.4 to close three dev server flaws, two rated medium and one rated low. The first, GHSA-rq7h-c2jc-7f22, scores 6.3 on CVSS 4.0. A project file whose path inside the root mirrors an absolute system path, say a folder called etc, could get the real host file served through the /@fs/ route, bypassing server.fs.allow. It affects every supported line from 6.4 to 8.3, and only on macOS and Linux.

The second, GHSA-vfpm-58rq-9qcg, also scores 6.3. Appending ?vite-wasm-instance to a request skipped the file system checks entirely. Vite then tried to parse the file as WebAssembly and the error message leaked its first four bytes. Four bytes sounds trivial. The advisory's own example is a .env file, where the first four bytes are the start of a secret's name. Only 8.2 and 8.3 are affected, and Bun users are not.

The third, GHSA-9jrq-w75r-8gcw, scores 2.1. A malicious site visited while your dev server runs could make the dev page load its script, but only when your own server code passes the raw request URL to transformIndexHtml. That is the pattern Vite's SSR guide documented for middleware mode, so custom SSR setups copied from the docs are the ones exposed.

Localhost vs --host: who is actually exposed

A Vite dev server bound to localhost is not reachable by the first two bugs from another machine. Once you pass --host or set server.host, anyone on the same network can send those requests. Both medium advisories name network exposure as a condition for the attack.

The comparison is worth spelling out, because the default and the habit point in opposite directions. Vite's default binds to localhost. Commerce teams override it all the time. Testing a product page on a real iPhone, checking a checkout flow on an Android tablet, letting a designer review motion on their own laptop: every one of those uses --host. Do that on a hotel or coworking Wi-Fi network and the dev server becomes a file server for strangers, limited only by the fixes in these releases.

The third bug flips the model. Localhost does not protect you, because the attack comes from your own browser visiting another site. What protects you is not passing an untrusted URL into transformIndexHtml. Standard SPA and MPA setups are not affected; hand-rolled Express or Fastify SSR servers often are.

Why it matters for headless commerce teams

Vite is the build and dev layer under most modern headless storefronts, which makes its dev server part of the commerce attack surface whether teams think of it that way or not. The Shopify Hydrogen skeleton runs on Vite 8 with React Router's dev plugin. Most React and Vue storefronts built on custom commerce APIs use it too, as do Tailwind v4 projects wired through its Vite plugin.

The risk is not the storefront in production. It is the developer laptop, which on a headless commerce project usually holds Storefront API tokens, Admin API keys, payment sandbox credentials and sometimes a production database dump for debugging. A .env file is the obvious target, and two of these bugs are file read paths. A leaked Admin API token is not a dev problem. It is a store problem.

There is also a lockfile trap. Hydrogen's skeleton declares Vite with a caret range starting at 8.0.1. A caret range allows the fix, but it does not install it. A project scaffolded in August still runs whatever the lockfile froze, which may be 8.2.x and inside the affected range for the WebAssembly leak.

What we would change this week

Upgrade Vite to a patched release on every active project, then stop treating --host as a harmless default. On the storefronts we build, the checklist looks like this.

1. Run npm ls vite in every repo, including ones where Vite is a transitive dependency of a framework. Anything below 8.3.3 on the 8.3 line, or below the matching patch on older lines, gets bumped and the lockfile committed.
2. Remove --host from the default dev script. Add a separate script for device testing so network exposure is a deliberate choice, not the thing that happens every morning.
3. Tighten server.fs.deny to cover .env*, key files and any local dump folder. The defaults help; explicit patterns help more.
4. Audit custom SSR entry files for transformIndexHtml(req.originalUrl, ...) or equivalent. Pass a normalised path, not the raw request URL.
5. Keep production secrets off dev machines. Scoped development tokens on a development store cost nothing and turn a file read bug into a non event.

None of this is dramatic. The CVSS scores are moderate and the preconditions are real. But dev server bugs keep arriving in Vite at a steady rate, and each one is cheaper to absorb when the habits above are already in place. The same discipline we applied to the Hydrogen hydration fix applies here: read the advisory, check the lockfile, ship the patch in the same week.

Where to dig deeper

• GHSA-rq7h-c2jc-7f22: files outside server.fs.allow served on non-Windows hosts
• GHSA-vfpm-58rq-9qcg: first bytes exposed through vite-wasm-instance
• GHSA-9jrq-w75r-8gcw: cross origin script execution in custom middleware