Automated Scans Exploit CVE-2026-39364 in Exposed Vite Dev Servers to Steal AWS and Azure Secrets

A wave of mass scans is targeting internet-exposed Vite development servers to extract sensitive files and obtain credentials for AWS and Microsoft Azure. The attacks exploit CVE-2026-39364, a flaw that allows unauthenticated file reads by bypassing the dev server’s access controls.

Security researchers have observed a sustained automated campaign that systematically probes publicly reachable Vite instances for clear-text secrets, with particular focus on AWS keys and Azure tokens. The activity relies on CVE-2026-39364 and has continued for weeks, producing thousands of repetitive, industrialized requests.

The vulnerability enables attackers to read files without authentication by circumventing the server.fs.deny mechanism. Malicious requests combine parameters such as ?raw and ?import to force the server to return the contents of targeted files. The distinctive symptom is an HTTP 200 response to requests against the /@fs/ endpoint.

Affected versions include Vite 7.1.0 up to but not including 7.3.2, and Vite 8.x up to but not including 8.0.5. Attackers are not primarily interested in application source code; they seek any file visible to the host, including .env files and infrastructure-as-code artifacts such as terraform.tfstate.

The campaign enumerates long lists of paths and filenames while employing path traversal and double-encoding techniques to evade reverse proxies and WAFs. A portion of the traffic originates from Google Cloud ranges 34.x and 35.x. Honeypot sensors recorded 807 sessions and approximately 32,000 events over a monthly window.

The risk is highest when development teams expose the server using the --host flag, server.host settings, or Docker port mappings. The default port 5173 becomes an entry point once reachable from the internet.

Immediate actions include upgrading to Vite 7.3.2, 8.0.5 or later, binding the server to localhost only, and blocking external access to port 5173 at the perimeter. Additional mitigations involve denying requests to /@fs/ and creating detection rules for suspicious query patterns. Any organization that previously exposed a vulnerable instance should rotate all potentially accessible secrets without delay.