Vite Dev Servers Under Attack: Why Your Cloud Credentials Are at Risk

Development servers are meant to run on a laptop, behind a firewall, for a few hours at a time. In practice they end up in Docker containers, cloud VMs and shared staging boxes, sometimes bound to every network interface and reachable from the internet. This month, security researchers reported that attackers are actively scanning for exactly that situation with Vite, one of the most widely used frontend build tools.

What was reported

According to security news coverage and an analysis published by F5 Labs, a mass-scanning campaign is targeting internet-exposed Vite dev servers. The attackers use an exploit for CVE-2026-39364, a high-severity flaw that lets an unauthenticated client bypass Vite's file-access restrictions by manipulating query parameters in an HTTP GET request. The result is that files outside the intended directories can be read in plain text.

The affected versions reported were Vite 7.1.0 through 7.3.2, and the 8.x branch before 8.0.5. The flaw was disclosed in April, and researchers say scanning activity rose sharply in August compared with the months before.

What the scanners are after is not the app's source code. Reports describe them looking for:

• AWS credentials and Azure access tokens
• Environment variables and .env files
• Infrastructure-as-code secrets such as state files

Why a dev-server bug becomes a cloud problem

A file-read bug sounds minor until you think about what sits next to your project on disk. A typical working directory holds .env files with API keys, a Terraform state file, a Kubernetes config, and sometimes cloud CLI credentials in the home directory. If a server can be tricked into reading any of those, the attacker no longer needs to break into your cloud account. They simply log in with your keys.

This is a good example of a pattern we see often: the vulnerable component is low-value, but the secrets nearby are high-value.

What to check today

You do not need to panic, but you should spend an hour on this if you use Vite.

1. Update Vite. Move to a patched release in your major line (for the 8.x branch, 8.0.5 or later; for 7.x, a version newer than 7.3.2). Check your lockfile, not just package.json, because the installed version is what matters.
2. Find exposed dev servers. Vite's default port is 5173. Review Docker Compose files, Kubernetes services, ingress rules, reverse-proxy configs and cloud security groups for anything that publishes that port to the internet.
3. Stop binding to all interfaces by default. The --host flag and server.host setting make the dev server reachable from other machines. Use them only when you need to, and only on a trusted network.
4. Rotate secrets that lived on an exposed machine. If a server was reachable and unpatched, treat any credentials on that host as potentially read. Rotate them and review your cloud audit logs for unfamiliar activity.
5. Do not run dev servers on production hosts. Serve built static assets instead. A production site has no reason to run a hot-reloading development tool.

Reduce the blast radius for next time

Patching fixes this bug, but the next one will look similar. A few habits make it much less painful:

• Give development machines and CI runners the smallest cloud permissions that work. Short-lived credentials are better than long-lived access keys.
• Keep secrets out of project directories where you can, using a secrets manager or your platform's environment injection.
• Require metadata-service protections on cloud instances, so that a stolen file or request cannot easily be turned into instance credentials.
• Put a firewall rule in place by default: dev ports are closed to the internet unless someone deliberately opens them.

Bottom line

The lesson is not that Vite is unusually unsafe. Any tool that serves files can have a path-handling bug, and any developer tool exposed to the internet will eventually be scanned. Keep your tooling updated, keep dev servers off public networks, and assume that whatever secrets are on a reachable machine are the real prize.

If you are not sure which of your environments expose development ports, that is worth an audit before an attacker does it for you.