Somebody is scanning the internet for developer laptops, and the patched version of Vite still hands over your npm token

There is a category of thing that never gets an inventory entry. It is not a server, it is not a laptop exactly, and nobody signed a contract for it. It is the little web server that starts when a developer types npm run dev, prints a URL in the terminal, and stops when they close the window.

For about six years the industry has treated that process as furniture. It runs on localhost. It is not production. Nobody thought about it.

In August, somebody ran roughly 32,000 requests at it looking for cloud credentials.

Everything below was checked against primary sources on September 16, 2026: F5 Labs’ telemetry write-up, the GitHub Security Advisory records for every Vite CVE involved, NVD, CISA’s Known Exploited Vulnerabilities feed, Vite’s own release changelogs and published packages, Vite and Astro documentation, and Docker’s official development guide. The version-by-version behaviour described in the middle of this article is our own testing, run this morning, and we have included the commands so you can repeat it.

What happened

On September 11, 2026, F5 Labs published honeynet telemetry from Adam Metcalfe-Pearce describing a sustained scanning campaign against Vite development servers. Vite is the build tool underneath most modern JavaScript frameworks, including Astro, Nuxt, SvelteKit, Remix, Qwik, Storybook and the Laravel front-end pipeline. If a shop has built a website in the last three years with anything other than WordPress, Vite is very likely in the toolchain.

The numbers are the story. In F5’s words:

the volume of Vite-related file-read attempts climbed from a baseline of 1,732 events over the prior three-month period to over 32,000 events in August alone

That is 807 session-grouped attacks and about 32,000 raw events in one month, against a baseline of roughly 578 a month. The scanners were not poking at random. They cycled through wordlists of environment files across every naming convention, AWS credential paths in every common home directory, Azure token files, terraform.tfstate, serverless.yml, and /proc/self/environ. This is a credential harvesting operation, and the merchandise is whatever is in your .env.

The traffic came predominantly from Google Cloud address ranges, 34.x and 35.x, with the largest volumes attributed to the United States (17,297 events), Belgium (4,407), the Netherlands (4,011), Singapore (2,842) and Taiwan (1,994).

The vulnerability being used is CVE-2026-39364, published April 6, 2026. GitHub’s advisory scores it 8.2 High on CVSS 4.0. NVD scores the same flaw 7.5 on CVSS 3.1, which is worth knowing only because you will see both numbers quoted as though one of them is wrong. Neither is. They are different scales.

What the bug actually does, precisely

The coverage says “read arbitrary files.” That is not quite it, and the difference determines whether you need to care.

A Vite dev server has two separate guards on file access. server.fs.allow decides which directories can be reached at all, and it defaults to the project workspace. server.fs.deny is a blocklist of patterns that are refused even inside the allowed directories, and it exists specifically so that your .env is not readable just because it happens to sit in your project folder.

CVE-2026-39364 defeats the second guard, not the first. In the advisory’s words, files that should be blocked by server.fs.deny, for example .env and *.crt, “can be retrieved with HTTP 200 responses when query parameters such as ?raw, ?import&raw, or ?import&url&inline are appended.” GitHub classifies it as CWE-180, Incorrect Behavior Order: Validate Before Canonicalize, which is the mechanism in one line: the deny check ran against the path as it arrived, with the query string still attached, so .env?raw?? did not look like .env to the blocklist, and then the resolver stripped the query and read .env anyway.

We set up a throwaway project on Vite 7.3.1 this morning, put a fake key in .env, started it with --host, and asked for the file six ways. Here is exactly what came back:

Request	Result
GET /@fs/<project>/.env	403 Restricted
GET /@fs/<project>/.env?raw	200, export default "SECRET_CANARY=not_a_real_key_12345\n"
GET /@fs/<project>/.env?raw??	200, same contents
GET /@fs/<project>/.env?import&raw	200, same contents
GET /@fs/<project>/.env?import&url&inline	200, contents base64 encoded in a data: URL
GET /@fs/etc/passwd?raw??	403 Restricted

The last row is the important one. With a default configuration, the allow list still held. The scanners’ /root/.aws/credentials and /proc/self/environ requests do not work against a normally configured project, and neither did the double-encoded traversal strings F5 observed, which in our test just returned the site’s own index.html.

They work against a project that has widened server.fs.allow, which is common and often necessary in a monorepo, where the dev server has to reach shared packages one or two directories up. We tested that too. With the allow list opened to the filesystem root, GET /@fs/tmp/outside/.env?raw?? returned the secret, where the same request without the query string returned 403.

So the honest summary is: this reads any file the dev server was already allowed to touch, including the ones specifically meant to be off limits. On a single-project setup that is your .env, your certificates and your .git directory. On a monorepo with a widened allow list it is considerably more.

The finding: the patched versions still serve your npm token

Here is the part we have not seen anywhere, and it is the reason this article exists.

Every piece of coverage ends with the same advice: upgrade Vite. It is correct advice and it closes the CVE. We upgraded, re-ran the test, and then tried a few other files that a developer would reasonably expect a security-conscious dev server to refuse.

On Vite 7.3.6, the newest release on the 7.x branch, released June 25, 2026, with a default configuration and no vulnerabilities reported by npm audit:

File	Plain GET	With ?raw??
.env	403	403
.npmrc	200	200
tls.key	200	200

.env is correctly protected. The patch works. But .npmrc, which on most machines contains an npm registry auth token, and tls.key, an RSA private key, are handed over on a plain unauthenticated GET. No vulnerability is involved. No query parameter trick is needed. The server is doing exactly what it was configured to do, because those patterns are not in its blocklist.

We then checked the default server.fs.deny value compiled into seven published Vite versions by reading it out of the packages themselves:

Vite version	Released	Default server.fs.deny
6.4.3	patched branch	.env, .env.*, *.{crt,pem}, **/.git/**
7.3.1	vulnerable	.env, .env.*, *.{crt,pem}, **/.git/**
7.3.6	2026-06-25	.env, .env.*, *.{crt,pem}, **/.git/**
8.0.5	2026-04-06	.env, .env.*, *.{crt,pem}, **/.git/**
8.0.16	2026-06-01	.env, .env.*, *.{crt,pem}, **/.git/**
8.1.0	2026-06-23	.env, .env.*, *.{crt,pem,key,p12,pfx,cer,der}, .npmrc, .yarnrc.yml, **/.git/**
8.2.2	2026-08-20	.env, .env.*, *.{crt,pem,key,p12,pfx,cer,der}, .npmrc, .yarnrc.yml, **/.git/**

The hardened list arrives in Vite 8.1.0, and Vite’s own changelog says why nobody heard about it. It is filed under Features:

• extend server.fs.deny list with common files (#22707)

A feature, not a security fix. Features do not get backported to maintenance branches, do not get a CVE, and do not appear in npm audit. Which means the entire population of projects following the advice in this month’s coverage, upgrading to the fixed release on whatever branch they are on, lands on a dev server that refuses .env and offers .npmrc.

Vite’s current documentation lists the long version as the default for server.fs.deny, because the docs describe the current release. If you are on 6.x, 7.x or 8.0.x, the documentation is describing a configuration you do not have.

And the loop closes badly. We ran npm audit on the vulnerable project, which correctly reported all five Vite advisories, then ran npm audit fix. It moved us to 7.3.6, reported the project clean, and left the short deny list in place. A clean audit is not the same as a protected token.

If you are staying on Vite 6 or 7, add this to your config and stop thinking about it:

// vite.config.js, or the vite block of astro.config.mjs
export default {
  server: {
    fs: {
      deny: [
        '.env', '.env.*', '**/.git/**',
        '*.{crt,pem,key,p12,pfx,cer,der}',
        '.npmrc', '.yarnrc.yml',
      ],
    },
  },
}

That is Vite 8.1’s default, written out by hand. Setting deny replaces the default rather than adding to it, which is why the original patterns are repeated above.

And check what your framework will actually give you. In most projects nobody installs Vite directly, so the version you get is decided by a range in your framework’s dependencies. Reading those ranges off the npm registry this morning: Astro 6.4.8 declares vite: ^7.3.2, which can never resolve to 8.x, so every Astro 6 project is on the short deny list and needs the block above. Astro 7.3.2, the current release, declares vite: ^8.0.13, which resolves to 8.3.0 on a fresh install and gives you the hardened list. But a caret range only decides what a new install gets. A lockfile written in April or May, when 8.0.x was current, pins a version with the short list and will keep pinning it until somebody updates it. npm ls vite tells you which case you are in, and it is the only thing that does.

The second finding: the recommended WAF rule misses the sibling bug

F5’s mitigation list is sensible and we would sign most of it. One item deserves a caveat:

block any request containing the /@fs/ path segment

That will stop the scanning campaign in this article, because the campaign uses HTTP requests to /@fs/. It will not stop CVE-2026-39363, published the same day, April 6, 2026, also scored 8.2, titled “Arbitrary File Read via Vite Dev Server WebSocket.”

That one is worse and it is not an HTTP path at all. From the advisory: the server.fs access control validation was not applied to the fetchModule method exposed through the dev server’s WebSocket. An attacker connecting to the WebSocket without an Origin header could call fetchModule with a file:// URL and ?raw and retrieve arbitrary file contents as a JavaScript string. There is no allow list involved, so the limit that saved the default configuration above does not apply here. It affects Vite 6.0.0 to 6.4.1, 7.0.0 to 7.3.1 and 8.0.0 to 8.0.4, and it is fixed in the same releases, 6.4.2, 7.3.2 and 8.0.5.

A path-based WAF rule does not see a WebSocket upgrade. If your answer to this month’s news is a firewall signature rather than an upgrade, you have covered the CVE that is being scanned and left the more powerful one in the same release untouched.

There were four Vite advisories in 2026, and the coverage names one:

CVE	Published	Severity	What it is
CVE-2026-39363	Apr 6	8.2 High	Arbitrary file read via the dev server WebSocket, bypassing server.fs entirely
CVE-2026-39364	Apr 6	8.2 High	server.fs.deny bypassed with query parameters, the one being scanned
CVE-2026-39365	Apr 6	6.3 Moderate	Path traversal in optimized deps .map handling
CVE-2026-53571	Jun 1	8.2 High	server.fs.deny bypass via Windows alternate path forms

The third finding: the upgrade target in the coverage is out of date

Nearly every article this week says the fix is 7.3.2 or 8.0.5. That was the fix in April. On June 1, 2026, Vite published CVE-2026-53571, another server.fs.deny bypass, this one using the alternate path forms Windows accepts, such as 8.3 short names on NTFS. It affects Vite 8.0.0 through 8.0.15, 7.0.0 through 7.3.4, and 6.4.2 and below. The fixed versions are 8.0.16, 7.3.5 and 6.4.3.

So a Windows shop that reads this week’s coverage, upgrades to exactly 7.3.2, and closes the ticket has patched April and not June. F5’s own recommendation is phrased correctly, “7.3.2, 8.0.5, or later point releases,” but the sentence that travels is the version number.

Current minimum safe versions, as of this morning: 8.0.16 on the 8.0.x line, 7.3.5 on 7.x, 6.4.3 on 6.x. Current latest is 8.3.0, and anything from 8.1.0 up also gets you the hardened deny list, which is the reason to go there rather than to the minimum.

One accuracy note while we are counting versions: several outlets state the affected range as “Vite 7.1.0 through 7.3.2.” The advisory says 7.1.0 through 7.3.1. 7.3.2 is the fix, not a casualty.

Why is a dev server reachable from the internet at all?

Every one of these advisories carries the same precondition, and it is the part that decides whether any of this is your problem. From the advisory text:

Only apps that explicitly expose the Vite dev server to the network (using --host or server.host config option) … are affected.

Vite’s default for server.host is localhost. Out of the box, nothing outside your machine can reach it. So the honest question is why tens of thousands of these are sitting on the open internet.

Three reasons, and none of them involve anybody being careless.

Containers. A dev server bound to localhost inside a Docker container is unreachable from the host, so it looks broken. The fix everybody applies is to bind to all interfaces. Docker’s own official React development guide instructs exactly this, with no security note attached:

server: {
  host: true,
  port: 5173,
  strictPort: true,
}

and in the accompanying compose file:

ports:
  - "5173:5173"

host: true is precisely the precondition in all four advisories. On a laptop behind a home router, publishing 5173 reaches your LAN. On a cloud VM used as a shared development box, with a permissive security group, it reaches everyone.

Testing on a phone. The other common reason for --host is looking at the site on a real handset. This is legitimate, ordinary work. It is also a coffee shop or a coworking floor where the wifi is shared with strangers.

The staging box that never got built properly. Somebody needed a URL to show a client, ran npm run dev on a VPS behind a reverse proxy, and it worked. Two years later it is still running.

Worth noting who says what here. Astro’s CLI documentation carries an explicit warning: “Do not use the --host flag to expose the dev server and preview server in a production environment. The servers are designed for local use while developing your site only.” Vite’s server options page documents host without any comparable caution. Docker’s guide hands you the configuration and says nothing. The warning exists, it is just not where most people encounter the setting.

The user agent detail, and why it breaks a popular defence

One piece of F5’s write-up deserves separate attention because it invalidates a control a lot of small sites have switched on in the last year.

The scanners forged their User-Agent headers to impersonate Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot and Amazonbot, and injected false X-Forwarded-For and X-Real-IP values on top. F5’s recommendation is blunt: “Do not rely on raw User-Agent headers to whitelist search engine or AI crawler traffic.”

We wrote last month about Cloudflare reclassifying AI crawlers and the defaults changing on September 15, and a lot of people responded by building allow rules for the crawlers they wanted to keep. If any of those rules match on user-agent strings alone, they are now a documented bypass. A user-agent header is a claim made by the client, and it costs an attacker nothing to make it. Google, OpenAI, Anthropic and the rest all publish verification methods, either reverse DNS or published IP ranges, and Cloudflare’s own verified-bot category does the checking for you. Match on the verified category, not the string.

This is the third year of the same bug

It would be easy to read this as a Vite problem. It is worth noticing the pattern instead.

CISA’s Known Exploited Vulnerabilities catalog, which we pulled this morning at version 2026.09.14, contains 1,710 entries, 226 of them added during 2026. One of them is a Vite dev server flaw. CVE-2025-31125 was added on January 22, 2026, and CISA’s own description of it will sound familiar:

Vite Vitejs contains an improper access control vulnerability that exposes content of non-allowed files using ?inline&import or ?raw?import. Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected.

That is the same bug as CVE-2026-39364, one year earlier, with confirmed exploitation attached. It had siblings: CVE-2025-30208, CVE-2025-31486 and CVE-2025-32395 were all server.fs.deny bypasses disclosed within a few weeks of each other in spring 2025. F5 reports that this August’s campaign was probing for the 2025 CVEs alongside the 2026 one, which tells you the operators expect to find unpatched machines from both years.

None of the 2026 Vite CVEs are in the KEV catalog as of this morning, despite 32,000 documented exploitation attempts in a month. That is not a criticism of CISA, whose evidence bar is specific, but it does mean that a triage process keyed to KEV alone will not flag this one.

The other dev-tooling entry in KEV is worth naming, because it makes the point better than we can. CVE-2025-11953, added February 5, 2026, is an OS command injection in the React Native Community CLI, where the Metro development server exposes an endpoint that lets “unauthenticated network attackers” run arbitrary executables. Two of the developer tools that ship on millions of machines are now in the catalog of things known to be exploited in the wild, and both entries are about a development server being reachable.

Running npm audit on our deliberately outdated test project produced two more in the same family that nobody wrote articles about: an esbuild advisory titled “esbuild allows arbitrary file read when running the development server on Windows,” and a launch-editor advisory for NTLMv2 hash disclosure through UNC path handling. The local development toolchain is now an attack surface with its own CVE stream, and most teams have never treated it as one.

The reason is structural rather than anyone’s fault. These servers were written to be convenient on a trusted machine. They have no authentication because there was nobody to authenticate. Every one of these CVEs is a variation on retrofitting a security boundary onto a program that was designed without one, which is why the same bug keeps coming back with a different query string.

Who is affected, and who is not

Because the coverage has been alarming and unspecific, it is worth being exact.

Not affected: your live website. Everything discussed here is the development server. A site built with astro build, vite build or any framework equivalent and deployed to Vercel, Netlify, Cloudflare Pages or a normal web server is serving static files or a compiled server bundle. There is no /@fs/ endpoint. Preview deployments on those platforms are builds, not dev servers, so they are fine too.

Not affected by default: a developer working on a normal machine. Bound to localhost, which is the default, nothing outside that machine can connect.

Affected: anything started with --host, server.host, or inside a container that publishes the port. That includes the Docker setup above, dev servers on cloud VMs, and any long-lived “staging” process running a dev command.

Affected and easy to forget: a laptop on shared wifi with --host running, at a coworking desk, a café, a hotel or a conference. The dev server is reachable by everyone on that network for as long as it is running.

Worth a look: your CI. Some end-to-end test pipelines start a dev server rather than a preview server. If those runners are on a network anything else can reach, the same request works there, and CI environments usually hold more credentials than a laptop does.

Default ports to look for: Vite is 5173. Astro’s dev server is 4321 and serves the same /@fs/ endpoint, because it is Vite underneath. Nuxt is 3000. The port is a hint, not the boundary, since any of them can be changed.

The sixty-second self-test

Run this against your own machine, on your own project. Start the dev server the way you normally start it, then:

# 1. What version of Vite is actually in this project?
npm ls vite          # or: pnpm why vite

# 2. Does the dev server answer anything other than localhost?
#    Look at the terminal. If it prints a "Network:" line with a
#    192.168.x.x or 10.x.x.x address, it is exposed to your LAN.

# 3. Ask it for your own .env, the way a scanner would.
curl -i "http://127.0.0.1:5173/@fs$(pwd)/.env?raw??"

# 4. Ask it for the files the 6.x/7.x/8.0.x blocklist does not cover.
curl -i "http://127.0.0.1:5173/@fs$(pwd)/.npmrc Updated September 20, 2026 with a second route to the same outcome: an AI coding agent uploading whole workspaces including .git, which makes the inventory problem behind this bug the thing worth fixing rather than the bug itself."

Use 4321 instead of 5173 for Astro. A 403 Restricted on all of them is the answer you want. A 200 on step 3 means you are running a vulnerable version and it is time to upgrade tonight. A 200 on step 4 means you are on a version older than 8.1.0 and should paste in the deny list above.

For completeness, we ran exactly this against our own site, which is built with Astro 7 on Vite 8.2.2. Every request returned 403, including all five bypass strings. We would rather check than assume, and it took a minute.

What to do

1. Upgrade Vite. Minimum 8.0.16, 7.3.5 or 6.4.3. Preferably 8.1.0 or later, because that is where the hardened deny list lives. In most projects Vite arrives through your framework, so the practical command is to upgrade the framework and then confirm with npm ls vite that the resolved version is what you expect.

2. If you cannot move to 8.1+, paste in the deny list by hand. The block earlier in this article. It takes thirty seconds and it protects the npm token that would let somebody publish packages as you.

3. Run npm audit on every project. Not because it is thorough, but because it catches this entire family in about ten seconds and most teams have not run it on a front-end project this year.

4. Take --host and host: true out of anything permanent. Use it deliberately when you need to test on a phone, and stop the server afterwards. If you need it constantly for container work, bind to the container network rather than all interfaces, or put the port behind your VPN rather than your cloud security group.

5. Find the staging box. If a dev command is running as a long-lived process anywhere with a public IP, that is the finding, independent of any CVE. Build the site and serve the output instead. It will also be about fifty times faster.

6. If any of this was exposed during August, rotate. F5’s guidance and ours: “Treat local .env variables, AWS credentials, Azure access tokens, and Terraform state files as potentially compromised and rotate the associated keys immediately.” On a typical small business project the .env holds a Stripe secret key, a database URL with its password, a mail API key such as Resend or SendGrid, and an admin or session signing secret. Every one of those is usable by a stranger without touching your site. We wrote a full walkthrough of what an exposed .env costs and how to check whether anyone used the keys, including how to read Stripe’s own request log for the key in question. This is the fifth distinct route to the same outcome we have covered this month, and the first one where the leak comes from a developer’s own machine rather than a server.

What we could not verify

• How many Vite dev servers are currently exposed. We found no figure from a source we could pull directly, and we are not repeating one. F5’s data measures attacks against its sensors, not the size of the target population.
• Whether the campaign is still running today. F5’s telemetry covers August 2026. The article was published September 11. Nothing we can check tells us what happened this week.
• Whether any small business has actually been compromised this way. No named victim exists in any source we read. The campaign is documented, the outcome is not.
• Attribution. The traffic came from Google Cloud ranges, which is rented infrastructure and says nothing about who rented it. The country breakdown is where the servers are, not where anybody is.
• Whether .npmrc and private keys were among the targeted wordlists. F5 lists environment files, cloud credentials and IaC state. Our finding about the short deny list is our own testing, and it describes an exposure that exists whether or not anyone is currently looking for it.
• The exact fixed-version boundary for CVE-2026-53571 on the 7.x branch. The advisory says 7.0.0 through 7.3.4 are affected and 7.3.5 is the fix. npm audit on our test project reported the vulnerable range as 7.0.0 to 7.3.3. We could not reconcile the two and went with the advisory, which is the stricter reading.

The short version

If your business has a website built in the last three years by anyone other than a WordPress shop, Vite is probably in it, and none of this touches your live site. It touches the machines where the work happens.

Ask whoever builds or maintains your site three questions. What version of Vite does the project resolve to, and is it at least 8.1.0. Is any dev server running with --host or inside a published container port anywhere that is not a laptop on localhost. And if either answer was yes at any point during August, have the keys in the environment file been rotated.

The one thing worth carrying away, if you are the person running the commands: patching Vite this week closes four CVEs and still leaves .npmrc readable, because the fix for that shipped as a feature in a minor release that nobody was told to install. A clean npm audit is not the same thing as a dev server that refuses to hand out your tokens.

If you want a second pair of eyes on any of it, get in touch. We are in Toronto, we run these checks on our own projects, and the ten-minute version of this conversation is considerably cheaper than the version that starts with a rotated Stripe key.

Update, September 20, 2026: the other way that file leaves your machine

The whole point of this post is that a credential you believed lived in exactly one place turned out to be readable over the network by anyone who could reach a dev server. Four days later, a different route to the same outcome.

ZCode, a desktop AI coding agent, was found packaging developer workspaces including the complete .git directory, encrypting them with a vendor-held key and uploading them to cloud object storage, with no mention of the behaviour in its privacy policy and two settings that did not stop it. A second agent from a different vendor had been caught doing a version of the same thing in July.

The connection is not the vulnerability. It is the inventory problem. .npmrc, .env, and everything in .git are all files people mentally file under “on my machine,” and this year has produced three separate demonstrations that the mental model is wrong. The durable fix is the same one recommended above: production values do not live in a directory a developer works in, in any branch, in any year. The write-up on coding agents and what they send is here.

Sources

• Cloud Takeover: Mass Scanning for Exposed Vite Endpoints (CVE-2026-39364), Adam Metcalfe-Pearce, F5 Labs, September 11, 2026, for the 807 sessions and roughly 32,000 raw events in August 2026, the quoted comparison with the 1,732-event three-month baseline, the per-country event counts, the Google Cloud source ranges, the targeted file wordlists, the forged Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot and Amazonbot user agents and the forged X-Forwarded-For headers, the observation that the campaign also probed CVE-2025-30208 and CVE-2025-31125, and the quoted WAF, user-agent and credential-rotation recommendations
• Vite: server.fs.deny bypassed with queries, GitHub Security Advisory GHSA-v2wj-q39q-566r for CVE-2026-39364, published April 6, 2026, for the CVSS 4.0 score of 8.2 and its vector, the affected ranges 7.1.0 to 7.3.1 and 8.0.0 to 8.0.4, the fixes in 7.3.2 and 8.0.5, the quoted description and query-parameter examples, the network-exposure precondition, and the CWE-180 and CWE-284 classifications
• Vite Vulnerable to Arbitrary File Read via Vite Dev Server WebSocket, GHSA-p9ff-h696-f583 for CVE-2026-39363, April 6, 2026, for the fetchModule WebSocket mechanism, the missing Origin header condition, the affected ranges including 6.0.0 to 6.4.1, and the fixes in 6.4.2, 7.3.2 and 8.0.5
• Vite Vulnerable to Path Traversal in Optimized Deps .map Handling, GHSA-4w7w-66w2-5vf9 for CVE-2026-39365, April 6, 2026, for the 6.3 moderate score and affected ranges
• vite: server.fs.deny bypass on Windows alternate paths, GHSA-fx2h-pf6j-xcff for CVE-2026-53571, published June 1, 2026, for the 8.2 score, the affected ranges up to 8.0.15, 7.3.4 and 6.4.2, the fixes in 8.0.16, 7.3.5 and 6.4.3, and the NTFS and 8.3 short-name preconditions
• NVD records for CVE-2026-39364, CVE-2026-39363 and CVE-2026-53571, queried through the NVD API on September 16, 2026, for the publication dates and the NVD CVSS 3.1 base score of 7.5 on all three, alongside the CVSS 4.0 score of 8.2 from the GitHub CNA
• Known Exploited Vulnerabilities Catalog JSON feed, CISA, downloaded September 16, 2026 at catalog version 2026.09.14, for the 1,710 entries, the 226 added during 2026, the full CVE-2025-31125 entry added January 22, 2026 including the quoted description, the CVE-2025-11953 React Native Community CLI entry added February 5, 2026 including its quoted description, and the absence of any 2026 Vite CVE. The counts are our own analysis of that file.
• Vite CHANGELOG for v8.1.0, retrieved September 16, 2026, for the release date of June 23, 2026 and the quoted Features entry “extend server.fs.deny list with common files” referencing pull request #22707
• Default server.fs.deny values read directly out of the published npm packages for Vite 6.4.3, 7.3.1, 7.3.6, 8.0.5, 8.0.16, 8.1.0, 8.2.2 and 8.3.0, and release dates and declared dependency ranges read from the npm registry metadata for the vite and astro packages, both on September 16, 2026, including the vite: ^7.3.2 range on Astro 6.4.8 and vite: ^8.0.13 on Astro 7.3.2. The version comparison table is our own testing.
• Request and response behaviour on Vite 7.3.1, Vite 7.3.6 and Astro 7.2.4 on Vite 8.2.2, tested locally on September 16, 2026 against throwaway projects containing canary values. The 403 and 200 results, the npm audit and npm audit fix outcomes, and the monorepo allow-list test are ours.
• Server Options, Vite documentation, for the server.host default of localhost, the server.fs.strict default of true, the description of server.fs.allow and server.fs.deny, and the documented current default deny list
• CLI Reference, Astro documentation, for the quoted --host description and the quoted warning against using it to expose the dev or preview server in a production environment
• Use containers for React.js development, Docker documentation, for the quoted host: true Vite configuration, the quoted explanation that it “allows the dev server to be accessible from outside the container,” and the "5173:5173" compose port mapping, published without a security caveat
• Mass-Scanning Campaign Exploits Vite Flaw to Extract Cloud Credentials From Exposed Dev Servers, The Hacker News, September 15, 2026, and Hackers target exposed Vite dev servers to steal AWS, Azure secrets, BleepingComputer, September 14, 2026, cited for the state of the coverage: both name CVE-2026-39364 only, both give the affected range as “7.1.0 through 7.3.2,” and neither mentions CVE-2026-39363, CVE-2026-39365 or CVE-2026-53571