A mass-scanning campaign targeting internet-exposed Vite development servers demonstrates how quickly developer tooling can become an entry point into cloud infrastructure when it is accidentally published to the internet. F5 observed more than 800 attack sessions and approximately 32,000 raw events during a month-long period, with attackers exploiting CVE-2026-39364, a high-severity unauthenticated file-read vulnerability affecting Vite 7.1.0 through versions before 7.3.2 and the Vite 8 branch before 8.0.5. The vulnerability allows an attacker to manipulate query parameters appended to requests against Vite’s filesystem-serving functionality so that files normally blocked by `server.fs.deny` are returned in plaintext. Rather than limiting themselves to application source files, the scanners systematically searched for `.env` files, AWS credential stores, Azure access tokens, Terraform state, Serverless configuration, process environment variables and other files likely to contain credentials that could be reused outside the development server itself. 

The most important security lesson is therefore that CVE-2026-39364 is not merely a file-disclosure issue. In a modern development environment, files are often where cloud authority lives. A `.env` file may contain database passwords, API keys and cloud service tokens, while `~/.aws/credentials` can contain AWS access keys and Terraform state can reveal infrastructure details, resource identifiers, outputs and occasionally sensitive values. Azure credential files and access tokens may similarly provide access far beyond the development machine. F5’s telemetry shows that attackers understand this perfectly well because their wordlists were explicitly built around cloud and infrastructure credentials rather than random local files.

That changes the risk model considerably. The attacker does not necessarily need remote code execution on the Vite host if the server willingly returns a credential that gives them access to AWS, Azure, databases, object storage or production infrastructure. The development server becomes an information bridge into the cloud control plane. In many cases, stealing one high-privilege API key may be more valuable than compromising the developer workstation itself because the stolen credential can be used directly against the cloud provider through legitimate APIs, potentially bypassing many endpoint-focused security controls.

F5 observed scanners looking for AWS credential files across numerous common home directories, including those belonging to `root`, `ubuntu`, `ec2-user`, `node`, `www-data`, `admin` and other service accounts. The attackers also probed for `.aws/config`, credential backups, AWS SSO caches, `rootkey.csv`, Azure credential files, `accessTokens.json`, Terraform state and variable files, Serverless state, `/proc/self/environ`, `/proc/1/environ` and `/proc/self/cwd/.env`. That last path is particularly revealing because querying `/proc/self/cwd/.env` avoids having to guess where the application lives on disk. The attacker simply asks the running process where its current working directory points and retrieves the corresponding environment file.

This shows that the campaign is not random vulnerability scanning in the traditional sense. It is automated cloud credential discovery. The scanners already understand common development stacks, Linux filesystem conventions, cloud CLI locations and Infrastructure-as-Code tooling. Their objective appears to be identifying secrets that can immediately be converted into cloud access rather than merely proving that the Vite server is vulnerable. F5 explicitly assessed the activity as an automated credential-harvesting campaign, and the sharp increase from a relatively low prior baseline to more than 32,000 Vite-related file-read events shows how quickly newly disclosed techniques are incorporated into mass exploitation frameworks.

The underlying vulnerability is straightforward. Vite exposes an internal `@fs` route to serve files during development and normally relies on `server.fs.deny` to block sensitive content such as `.env` files, certificates, keys and repository metadata. CVE-2026-39364 allows an attacker to append specially formed query parameters such as `?raw`, `?import&raw`, or related combinations in a way that bypasses the deny-list check. The vulnerable server then returns the requested file with an HTTP 200 response. Authentication is not required.

The vulnerability itself is dangerous, but external exposure is what turns it into an easily exploitable internet problem. Vite binds to `localhost` by default, which means the development server is not normally reachable from external systems. The risk appears when developers start Vite using `--host`, configure `server.host` to listen on all interfaces, expose container ports through Docker, or place the service behind a reverse proxy accessible from the internet. Vite’s own documentation explicitly notes that setting the host to `0.0.0.0` or `true` causes the development server to listen on LAN and potentially public interfaces.

This is an important architectural point because Vite is a development tool, not a hardened production web server. Development servers prioritize convenience, hot reloading, filesystem access and rapid feedback. Those capabilities make them extremely useful to developers and potentially dangerous when the network boundary protecting them disappears. Publishing a development server to the internet effectively converts development convenience features into public attack surface.

The problem is made worse by modern container and cloud workflows. Developers may run Vite inside Docker and map port 5173 to the host for convenience. A cloud development VM or temporary test environment may then receive a public IP address, leaving the port reachable from the internet without anyone consciously deciding to publish a development service. Temporary environments have an unfortunate habit of becoming permanent enough for attackers to find them.

Organizations therefore need to treat development infrastructure as part of their external attack surface. Asset-discovery systems should identify Vite services, development ports and reverse-proxy routes exposed beyond trusted networks. Port 5173 is a useful indicator, but defenders should not rely exclusively on the default port because Vite can be configured to listen elsewhere and automatically chooses another port if the preferred one is unavailable.

The credential angle also highlights a common misunderstanding around Vite environment variables. Vite intentionally exposes variables beginning with `VITE_` to client-side application code, and its documentation explicitly warns that these values should not contain sensitive information because they are bundled into the client. Variables without the `VITE_` prefix are not automatically exposed to browser code, but they may still exist in local `.env` files on the development host. CVE-2026-39364 makes that distinction less comforting if the attacker can directly retrieve the underlying file from the filesystem.

This is why secrets should not be treated as safe merely because an application framework promises not to expose them to client-side JavaScript. The real question is whether the file containing those secrets can be read by the process, exposed through tooling, copied into a container image, committed into a repository, leaked through logs or retrieved through another vulnerability. Secret management needs to assume that development files are eventually discoverable and therefore minimize the lifetime and privilege of anything stored inside them.

Long-lived AWS access keys are especially problematic in this scenario. If an attacker steals a static access-key pair from `.aws/credentials`, the credential may remain usable long after the Vite vulnerability is patched. The same is true for persistent Azure tokens, database passwords or infrastructure credentials. Organizations with publicly exposed vulnerable Vite servers should therefore not treat patching as the end of the incident. F5 recommends rotating all secrets that were reachable from the affected environment, which is appropriate because successful file retrieval leaves no guarantee that those credentials remain private.

The preferred long-term design is to reduce dependence on static credentials altogether. Development and CI environments should increasingly use short-lived cloud identities, workload federation, instance roles or managed identities rather than permanent access keys stored in local files. If credentials automatically expire or are bound to a specific workload, the value of a stolen `.env` file drops substantially. The application may still leak sensitive information, but the attacker receives something with limited lifetime and restricted scope rather than a reusable master key to the cloud account.

Least privilege is equally important. A developer’s AWS credential should not have administrative permissions merely because configuring granular IAM roles is inconvenient. If the credential can only read from a development S3 bucket or deploy into a test account, leakage remains serious but contained. If the same credential can create IAM users, access production secrets or modify production infrastructure, one exposed Vite server can escalate into a cloud-account compromise.

Terraform state deserves particular attention because it is frequently underestimated. Terraform state contains detailed information about managed infrastructure and may contain outputs or sensitive values depending on configuration and provider behavior. Attackers stealing `terraform.tfstate` gain a highly structured map of the environment, including resource names, cloud identifiers, networking information and relationships between services. Even where credentials are not directly present, the state can greatly accelerate reconnaissance and help attackers understand where to move next.

F5 also observed attackers using traversal and double-encoding variations, including double-encoded separators designed to bypass normalization performed by reverse proxies and web application firewalls. This is significant because organizations may believe a WAF or reverse proxy automatically neutralizes the vulnerability. Attackers are already testing variants intended specifically to exploit differences between how front-end infrastructure and Vite normalize paths and query parameters.

A WAF or IPS can still provide valuable protection by detecting suspicious `@fs` requests, traversal patterns and known query combinations, but it should be treated as a compensating control rather than a substitute for updating Vite and removing public exposure. Query-string parsing differences between layers are notoriously difficult to defend through signatures alone, particularly once attackers begin modifying encoding and delimiter combinations.

F5 also found scanners impersonating legitimate crawler User-Agent strings such as Googlebot, ClaudeBot, GPTBot, PerplexityBot and other well-known services. This is another useful lesson because User-Agent headers are completely attacker-controlled. A request claiming to originate from a search engine or AI crawler deserves no special trust unless the source is independently validated. Allowlisting traffic merely because the header says “Googlebot” is the web-security equivalent of opening the office door because someone wrote “employee” on a sticker.

The scanning infrastructure itself was heavily distributed through cloud hosting, particularly Google Cloud address space, with activity also observed from multiple geographic regions. This makes broad geographic blocking relatively ineffective. Attackers increasingly operate from major cloud providers because that infrastructure is cheap, scalable and frequently trusted by defenders. Blocking an entire country or cloud provider is usually impractical, so defenses need to concentrate on the nature of the request rather than simply where it originates.

The fact that the attackers also attempted older Vite vulnerabilities such as CVE-2025-30208, CVE-2025-31125 and CVE-2024-45811 is equally revealing. The scanning framework is evidently prepared to try multiple historical access-control bypasses against the same target rather than relying only on the newest CVE. This is typical of automated exploitation systems: once a host has been identified as running a particular technology, the attacker cycles through every inexpensive exploit that might work.

This means organizations cannot assume that fixing CVE-2026-39364 alone is sufficient if the Vite installation remains significantly outdated. The correct remediation is to update to a current supported version containing fixes for the relevant file-access issues, not merely patch one CVE in isolation while preserving exposure to several older bypasses.

Developers should also review `server.allowedHosts`, `server.cors` and filesystem settings rather than enabling permissive values for convenience. Vite’s own documentation warns that setting `server.allowedHosts` to `true` can expose the server to DNS rebinding attacks and recommends explicitly specifying trusted hosts. It similarly warns that enabling unrestricted CORS can allow websites to request source code and other content from the development server. These options exist because development tooling routinely trades restrictive defaults for usability once administrators intentionally loosen configuration.

From a monitoring perspective, defenders should search reverse-proxy and web logs for requests to `@fs` paths combined with query parameters such as `raw`, `import`, `url`, or `inline`, particularly when requests target `.env`, `.aws`, `.azure`, Terraform, `/proc` or system configuration paths. F5’s telemetry provides concrete examples of the probing patterns attackers are currently using. A single request for `/@fs/root/.aws/credentials` should probably not be filed under normal developer activity with a cheerful green checkmark.

Cloud telemetry should also be examined if credential exposure is suspected. Administrators should look for AWS or Azure logins from unfamiliar locations, unusual API calls, new IAM identities, credential creation, access to secrets stores, enumeration of storage resources or changes to infrastructure immediately following suspected exploitation. If the attacker successfully retrieved cloud credentials, the next stage may occur entirely within AWS or Azure rather than on the original Vite server.

This is where development security, network security and cloud security need to connect. The initial indicator may be an HTTP GET request hitting a forgotten dev server, while the actual compromise appears later as valid API calls against a cloud account. Without correlation across those layers, each event can appear benign in isolation.

The campaign therefore demonstrates why exposed development infrastructure deserves much more security attention than it traditionally receives. Development systems are often treated as low-value because they do not host production customer traffic. In reality, they may contain more useful secrets than production systems because developers need credentials to build, test and deploy applications. Source code, cloud tokens, Terraform state, package-registry credentials, database passwords and CI configuration frequently converge in the development environment. Attackers understand this. They are not scanning exposed Vite servers because they have an emotional attachment to JavaScript build tools. They are scanning them because development servers can contain the credentials that lead somewhere more valuable. 

The broader lesson from CVE-2026-39364 is therefore simple: development infrastructure should not be regarded as harmless simply because it is temporary or non-production. If a service can read credentials capable of controlling production infrastructure, then that service is part of the production security boundary whether the asset inventory agrees or not. A Vite development server exposed to the internet may look like a forgotten port on a test machine. To an attacker, it may look like an unauthenticated API for downloading the keys to AWS and Azure.

A mass-scanning campaign targeting internet-exposed Vite development servers is attempting to steal cloud credentials and configurations from AWS and Azure deployments. [...]

Source: Hackers target exposed Vite dev servers to steal AWS, Azure secrets via Bleeping Computer — published 14 Sep 2026.