Build1 publisher2 min readPublished
A query string walks past server.fs.deny on Vite dev servers left on a public port
F5 counted about 32,000 events in August aimed at .env files and cloud credentials on internet-reachable Vite development servers. The fixed builds are 7.3.2 and 8.0.5, and the advice pairs them with binding the server back to localhost.
The Engineer · Build desk
What happened
- F5 observed about 32,000 events in August 2026 aimed at .env files and cloud credentials on public Vite development servers, including probes for CVE-2026-39364 and older Vite vulnerabilities.
- For CVE-2026-39364, requests carrying particular queries may retrieve files that server.fs.deny is supposed to block, and F5 saw the probes hitting endpoints such as /@fs/.
- The remediation is to move 7.x installs to 7.3.2 or later and 8.x installs to 8.0.5 or later.
- F5 also advises limiting development servers to localhost or required networks and blocking outside connections to the actual listening ports, including 5173/TCP, because changing ports alone is not sufficient.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Any host answering HTTP on a dev port is reachable by a stranger with no credentials and no click required. The report notes that on-screen warnings may not appear, so the developer whose laptop is serving the project sees nothing.
- decision What to inventory is the running process: a patched Vite on a public interface still answers everyone, so the second half of the work belongs to whoever controls the network.
- constraint A directly exposed server bypasses the proxy log, the first place most teams would look. An investigation runs instead on Vite's own records and on cloud audit trails that a development box was probably never wired into.
- contradiction F5's 32,000 measures attempts, and F5 did not publish a figure for successful retrievals at ordinary organisations. The credential-theft reading rests on what the mechanism permits, while the measured quantity is scan volume.
The Vite project titles its advisory "server.fs.deny bypassed with queries (CVE-2026-39364)" [24]. F5's traffic matches that description: requests to /@fs/ endpoints, with raw and import queries attached [6][15]. The request signature is greppable. The writeup does not explain how the query defeats the deny-pattern match.
A file comes back only when three conditions hold at once: the path sits inside server.fs.allow, it matches a server.fs.deny pattern, and the Vite process can read it [8]. So the bug widens what is readable inside the root already being served, and F5 notes that retrieval does not succeed for all scanned paths [9]. A .env in the project directory is the interesting case. A secret stored outside server.fs.allow is not reachable this way [8].
The published affected range starts at 7.1.0 [10], so an install pinned at 7.0.x sits outside it [2]. The same list carries a second condition that no upgrade touches: the development server is reachable by the attacker [10].
F5's August honeynet figures were 807 attacks aggregated by session and roughly 32,000 events [4][1]. That is about 40 requests per session [1], consistent with a scanner walking a candidate path list rather than aiming at one known file.
BleepingComputer, listed in the report as a related source, headlines the activity "Hackers target exposed Vite dev servers to steal AWS, Azure secrets" [23]. The report itself marks the step from leaked credentials to environment takeover as an inference [25].
If the server answered the internet directly, the requests never reach a proxy log [16]. That leaves Vite's own records: startup arguments, listening addresses, configuration files, and file reads where auditing is enabled [17]. Reads over HTTP do not spawn a child process, so process-creation telemetry stays quiet [17]. On the cloud side, requests to Vite alone do not confirm compromise. Confirmation has to come from AWS or Azure audit logs showing API operations, permission changes or data access with the suspect credentials [18]. Flow records will not identify which file left, because TLS hides the contents [20]. The bar the report sets for proving unauthorised access is target file contents appearing in responses to the attacker [27].
The report also notes that email logs are not a source for confirming initial intrusion [19].
What to watch
- A published count of successful file retrievals would move this from scanning volume to measured loss.
- Cloud audit entries showing API calls from credentials first seen in a /@fs/ response would close the chain F5 labels an inference.
- Any further advisory on the 7.3.x or 8.0.x lines, now that the deny list is a known target.