This content was generated with the help of AI and published without prior human review. It may contain errors and is not professional advice. Report a problem: info@delionsoft.com.
A mass-scanning campaign is hunting for Vite development servers that are reachable from the internet and trying to read cloud credentials out of them. According to the original report, F5 recorded the activity on its honeypot sensors: roughly 800 attacks and about 32,000 raw events over a month. The attackers exploit CVE-2026-39364, a high-severity file access control bypass, and also reuse several older Vite flaws.
What happened
CVE-2026-39364 affects Vite 7.1.0 through 7.3.2 and the 8.x branch before 8.0.5, and was disclosed on 7 April. An unauthenticated request with certain query parameters appended — ?raw, ?import&raw and similar variants — causes the dev server to skip its deny-list filtering and return the requested file in plaintext with an HTTP 200 response.
Once a vulnerable server responded, the scanners worked through long wordlists aimed at secrets: .env files and their production and local variants, AWS credential and configuration files in several possible home directories, credential backups, Azure credentials and access tokens, Terraform state and variable files, serverless configuration and state, plus /proc/self/environ, /proc/1/environ and /etc/passwd. The campaign also tried path traversal and double-encoded traversal sequences, which F5 reads as an attempt to slip past reverse proxy or WAF normalisation.
Most traffic came from the United States, Belgium and the Netherlands, with Google Cloud IP ranges used to blend in. The most active sources also exploited older Vite access control flaws — CVE-2025-30208, CVE-2025-31125 (flagged as actively exploited) and CVE-2024-45811.
Vite binds to localhost by default. The report notes the usual reasons servers end up public anyway: the --host flag, an explicit server.host setting, or Docker port mappings that publish more than intended.
Why it matters
This is not an attack on production infrastructure; it is an attack on the developer machine, the shared staging box, or the container that someone spun up to demo a branch. Those environments are where full-privilege cloud keys, Terraform state and unscrubbed .env files tend to live, and they are rarely covered by the controls applied to production. A single readable .env can hand over an AWS or Azure identity that has far more permission than the frontend it was meant to serve.
The volume matters too. This is indiscriminate scanning, so exposure does not need to be long or well known to be found. A dev server left on --host inside a cloud VM for an afternoon is enough.
What to do
- Update Vite to a version that fixes CVE-2026-39364 — 7.3.3 or later on the 7.x line, 8.0.5 or later on 8.x — and audit which repositories still pin affected versions.
- Inventory anything listening on port 5173 from outside your network, including Docker port mappings and cloud VMs used for previews. Block the port at the perimeter and treat any public dev server as a misconfiguration to be fixed, not firewalled around.
- If a vulnerable server was exposed, assume the secrets it could reach are compromised and rotate them: cloud access keys, tokens, anything in Terraform state. F5 also suggests blocking suspicious
/@fs/requests and not granting trust based on crawler User-Agent strings. - Stop shipping long-lived cloud keys to developer machines. Short-lived credentials via SSO or OIDC limit the value of anything that leaks this way.