- The Mess: Attackers are mass-scanning internet-exposed Vite development servers and abusing CVE-2026-39364 to pull files that administrators thought were protected. F5 telemetry recorded more than 32,000 related events in August, with probes aimed directly at
.env, AWS credentials, Azure tokens and Terraform state. - The Damage: One exposed development server can hand an attacker cloud credentials, database passwords and infrastructure secrets without requiring authentication.
- The Fix: Upgrade Vite, stop exposing development servers to the Internet, and rotate any credentials that may have been readable from an exposed instance.
Vite is supposed to make frontend development fast.
It is not supposed to become a remote file server for whoever happens to scan your IP.
That is exactly what is happening now.
F5 Labs observed a sustained automated campaign against internet-exposed Vite development servers. Its sensors recorded 807 session-grouped attacks and roughly 32,000 raw events during August 2026. The attackers were not randomly poking at JavaScript files. They were systematically looking for credentials and infrastructure data.
The vulnerability behind the campaign is CVE-2026-39364, a high-severity file-read and access-control bypass affecting the Vite development server.
The Vite project rates it High, with affected versions including 7.1.0 through 7.3.1 and 8.0.0 through 8.0.4. The fixed releases are 7.3.2 and 8.0.5.
The vulnerability is not complicated
Vite exposes an internal @fs route that allows the development server to serve files from the filesystem.
That functionality is not inherently dangerous. The problem is the security boundary around it.
Vite uses server.fs.deny to prevent access to sensitive files such as .env and certificates.
CVE-2026-39364 allows an attacker to bypass that deny-list using specially crafted query parameters.
The Vite advisory explicitly describes the issue as files blocked by server.fs.deny becoming retrievable through HTTP requests.
F5 observed requests using variants such as:
/@fs/.env?raw??
/@fs/root/.env?raw??
/@fs/../.env?raw??
It also observed double-encoded traversal attempts targeting locations such as:
/proc/self/environ
The interesting part is not the syntax.
The interesting part is what comes next.
Attackers are hunting secrets, not source code
F5’s telemetry shows that the scanners are using extensive wordlists containing predictable locations for cloud and infrastructure credentials.
Targets included:
.env
.env.local
.env.production
.env.development
.env.staging
AWS credential locations included:
/root/.aws/credentials
/home/ubuntu/.aws/credentials
/home/ec2-user/.aws/credentials
/home/node/.aws/credentials
/home/www-data/.aws/credentials
The scanners also searched for:
terraform.tfstate
terraform.tfvars
.aws/config
aws-exports.js
amplifyconfiguration.json
.azure/credentials
.azure/accessTokens.json
And they went after process information:
/proc/self/environ
/proc/1/environ
/proc/self/cwd/.env
This is not vulnerability research.
This is credential harvesting.
F5 specifically describes the observed operation as automated reconnaissance targeting exposed development tooling, with attackers prioritizing cloud credentials and Infrastructure-as-Code state.
The dangerous part is the deployment mistake
Under normal conditions, Vite binds to localhost.
That is exactly what you want for development.
The problem begins when somebody decides the development server needs to be reachable from another machine and enables something like:
--host
or configures:
server.host
The same problem appears when Docker, Kubernetes, a reverse proxy or cloud infrastructure accidentally publishes the development port externally.
Now the architecture changes:
Developer laptop
|
v
Vite development server
|
+---- localhost <- relatively sane
|
+---- 0.0.0.0:5173 <- interesting
|
v
Internet
|
v
automated scanner
|
v
/@fs/.env
There is no authentication step in the vulnerability itself.
The attacker sends an HTTP request.
Vite processes it.
The access-control check can be bypassed.
The file comes back.
That is a terrible equation when the requested file contains:
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=...
JWT_SECRET=...
STRIPE_SECRET_KEY=...
One HTTP response can turn a frontend development mistake into a cloud-security incident.
The cloud angle makes this much worse
A leaked .env file is not automatically catastrophic.
Sometimes it contains harmless development configuration.
Sometimes it contains the keys to the kingdom.
Cloud credentials are particularly dangerous because their value is determined by IAM permissions.
An attacker who obtains a low-privilege key might gain access to one storage bucket.
An attacker who obtains an overprivileged deployment credential might be able to:
- enumerate cloud resources;
- read object storage;
- access databases;
- modify infrastructure;
- create additional credentials;
- deploy malicious workloads;
- access CI/CD systems;
- pivot into production.
Terraform state deserves special attention.
Teams frequently underestimate it because it is “just infrastructure state.”
It isn’t.
Depending on configuration and provider behavior, Terraform state can contain resource metadata and sensitive values. Exposing the state file can give an attacker a detailed map of the infrastructure and potentially secrets that were stored in state.
That makes the Vite issue much more interesting than a normal local file disclosure.
The scanners are already automated
The strongest part of F5’s research is the telemetry.
During August, information-leakage activity associated with the Vite campaign accounted for 32,010 events in its sensor data. F5 also observed predictable-resource-location and path-traversal activity.
The traffic wasn’t coming from one random attacker.
F5 observed multiple cloud-hosted source addresses and large volumes from infrastructure associated with Google Cloud ranges.
The scanners also used fake User-Agent strings pretending to be major crawlers and AI bots.
That matters because some environments still make security decisions based on:
User-Agent: Googlebot
or similar headers.
That is not authentication.
Anyone can send a fake User-Agent.
F5 explicitly observed forged crawler identities during this campaign.
The attack chain is brutally simple
The practical chain looks like this:
1. Find exposed Vite server
↓
2. Identify Vite version / behavior
↓
3. Request /@fs/
↓
4. Add crafted query parameters
↓
5. Bypass server.fs.deny
↓
6. Read .env / credentials / IaC state
↓
7. Validate stolen secrets
↓
8. Attack cloud infrastructure
There is no need for a sophisticated exploit chain.
No malware needs to be executed on the developer’s workstation.
No phishing email is required.
No password needs to be guessed.
The vulnerable service simply gives the attacker information that should never have crossed the network boundary.
This is why development infrastructure belongs behind a wall
The simplest mitigation is also the one developers most frequently ignore:
Do not expose Vite development servers to the public Internet.
Vite is a development tool.
It should normally listen locally.
If remote access is required, put it behind a properly controlled network boundary rather than publishing port 5173 directly to the Internet.
Audit:
Docker port mappings
Kubernetes Ingress
Cloud security groups
Load balancers
Reverse proxies
VPN access
Firewall rules
Development/staging DNS
Look specifically for configurations that effectively do this:
Internet → :5173 → Vite
That should immediately attract attention.
Patch the software anyway
Network isolation is not a replacement for patching.
The official Vite advisory lists the vulnerable ranges as:
7.1.0 – 7.3.1
8.0.0 – 8.0.4
and fixed versions:
7.3.2
8.0.5
The current recommendation is simple:
npm update vite
Then verify the actual dependency tree rather than assuming the package was updated:
npm list vite
For repositories using lockfiles, inspect the lockfile as well.
A globally installed or transitive copy can otherwise remain vulnerable even when the package definition looks clean.
If the server was exposed, assume the files were read
This is the part administrators should not skip.
Suppose a Vite server was publicly accessible in August.
Suppose it was running a vulnerable version.
Suppose .env existed.
You cannot prove safety merely because you do not see a successful attack in the application logs.
F5’s campaign was automated and used multiple request variants.
Treat potentially exposed credentials as compromised.
Rotate:
- AWS access keys;
- Azure tokens;
- database credentials;
- API keys;
- deployment credentials;
- CI/CD secrets;
- application signing secrets where appropriate.
Then inspect cloud audit logs.
For AWS, investigate CloudTrail.
For Azure, inspect Entra ID and Azure activity logs.
Look for:
new access keys
unusual API calls
new IAM users
policy changes
new roles
unexpected regions
new compute instances
object-storage access
secret-manager access
A Vite vulnerability does not automatically mean the attacker reached production.
But if the exposed .env contained production credentials, the incident has already crossed that boundary.
There is another uncomfortable lesson here
Vite is not the only problem.
The deeper issue is the habit of exposing developer tooling as if it were production infrastructure.
The same pattern appears with:
Webpack dev servers
Storybook
Jupyter
debug interfaces
local admin panels
development APIs
test dashboards
internal Grafana instances
CI runners
Developers often assume:
“It’s only a development server.”
Attackers see:
“It’s an unauthenticated HTTP service.”
Those are radically different threat models.
A development server does not become secure because nobody intended to put it on the Internet.
The moment it gets a public IP, a security group rule, a Kubernetes Ingress or a careless Docker mapping, it becomes part of the attack surface.
What defenders should check today
For organizations using Vite:
1. Find exposed instances
Search external assets for Vite development ports and HTTP responses characteristic of the development server.
2. Check the version
Anything inside the vulnerable ranges needs attention.
3. Review server.host
Do not assume localhost exposure.
Check the actual runtime configuration.
4. Inspect Docker and Kubernetes
A single:
ports:
- "5173:5173"
can be enough to expose a development service depending on the surrounding network configuration.
5. Search for .env exposure
Look at reverse-proxy logs and HTTP access logs for requests containing:
/@fs/
and suspicious query parameters.
6. Rotate credentials
If the server was exposed while vulnerable, rotate secrets rather than merely patching Vite.
7. Audit cloud activity
Patching the server does not invalidate credentials that may already have been copied.
Bugstoday’s take
This is exactly the kind of vulnerability that gets underestimated because the vulnerable component is called a development server.
That label means nothing once the service is reachable from the Internet.
CVE-2026-39364 is not interesting because somebody discovered a clever query-string trick. It is interesting because automated scanners are already using that trick against real infrastructure, and their target list is brutally practical: .env, AWS credentials, Azure tokens, Terraform state and process environment data.
The lesson is painfully simple:
Don’t put developer tooling on the public Internet and then hope server.fs.deny will save you.
Patch Vite.
Kill unnecessary Internet exposure.
Rotate anything that might have been readable.
And stop treating localhost software as harmless just because the README calls it a development server.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Vite security advisory — CVE-2026-39364
- F5 Labs — Cloud Takeover: Mass Scanning for Exposed Vite Endpoints
- NVD — CVE-2026-39364
- Vite Security Policy
