high

CVE

CVE-2026-53571

CWE

CWE-22, CWE-200

Affected Surface

`vite` versions `< 6.4.3`, `>= 7.0.0 < 7.3.5`, and `>= 8.0.0 < 8.0.16`, `vite-plus` versions `< 0.1.24`, Windows-hosted Vite dev servers exposed via `--host` or `server.host`, Projects that keep `.env`, `.env.*`, `*.crt`, or `*.pem` files inside directories allowed by `server.fs.allow`

CVE-2026-53571 is a Windows-specific file-disclosure bug in Vite’s dev server. It matters because it breaks a control many teams treat as a hard safety boundary during development: server.fs.deny.

Vite explicitly documents that server.fs.deny blocks sensitive files such as .env, .env.*, and *.{crt,pem} from being served. On vulnerable Windows builds, that guarantee can be bypassed by asking for the same file through an alternate pathname that Vite failed to reject before access checks were applied.

The advisory’s simplest proof of concept is short and high signal:

GET /.env::$DATA?raw

On affected systems, that request can return the contents of .env even though .env is on the deny list.

Affected versions

Affected npm packages:

  • vite versions < 6.4.3
  • vite versions >= 7.0.0 and < 7.3.5
  • vite versions >= 8.0.0 and < 8.0.16
  • vite-plus versions < 0.1.24

Patched versions:

  • vite 6.4.3
  • vite 7.3.5
  • vite 8.0.16
  • vite-plus 0.1.24

Check direct and transitive use:

npm ls vite vite-plus

Because Vite often arrives through higher-level frameworks and toolchains, some teams will be exposed without declaring vite directly in the top-level application package.

When exploitation is possible

The vulnerability is not “every Vite server on every platform.” The exploit window is narrower, but still common enough to matter.

The exposed setup needs all of the following:

  1. the dev server is reachable beyond localhost, typically through --host or server.host
  2. the target file is inside a directory Vite is willing to serve from through server.fs.allow
  3. the server is running on Windows, or the sensitive file lives on an NTFS volume where the alternate path form resolves

That means the highest-risk cases are:

  • Windows developer workstations running Vite on 0.0.0.0 for LAN testing
  • internal demo or preview environments that mistakenly reuse dev-server settings
  • shared Windows build or QA hosts where Vite is exposed to other users or subnets

If the dev server stays on default localhost-only settings, the bug is much harder to exploit remotely. But once host: true or a broad bind address is added, server.fs.deny stops being the safety net teams thought it was.

The vulnerable boundary

A typical Vite configuration may look roughly like this:

import { defineConfig } from "vite";

export default defineConfig({
  server: {
    host: true,
    fs: {
      allow: ["."],
      deny: [".env", ".env.*", "*.{crt,pem}"]
    }
  }
});

Developers reading that config reasonably expect requests for .env or tls.pem to fail. On affected Windows systems, Vite checked the incoming path too early and against the wrong normalized representation.

The advisory calls out two Windows pathname forms that matter:

  • NTFS alternate data streams, for example /.env::$DATA?raw
  • 8.3 short-name aliases, where a file may be reachable through a DOS-style shortened path name

The first case is the easier one to reason about. Windows treats file::$DATA as the default data stream of file, but a path filter that only looks for exact blocked names may see /.env::$DATA as a different string.

So the real resolution path is effectively:

incoming URL: /.env::$DATA?raw
  -> Vite checks deny list against alternate path form
  -> path not rejected
  -> Windows resolves ::$DATA to the file's default stream
  -> .env contents returned to the browser

The same logic applies to certificate material such as tls.pem when it sits inside the served tree.

Root cause and fix

The public fix trail is concise and useful. In the 8.x line, Vite merged PR #22572, titled fix: reject windows alternate paths, and released that change in v8.0.16.

The merged fix commit was:

dc245c7  fix: reject windows alternate paths (#22572)

The 6.x line received the same backport in:

96b0c10  fix: backport #22572, reject windows alternate paths (#22576)

The important security point is what changed conceptually: Vite stopped trying to reason about these Windows alternate path forms as acceptable requests and instead rejected them before the deny-list boundary could be bypassed.

There was also an adjacent Windows hardening change in the same 8.0.16 release:

50b9512  fix(deps): reject UNC paths for launch-editor-middleware (#22571)

That is a separate bug, but it reinforces the broader lesson: Windows pathname handling is full of alternate syntaxes that break naive security checks.

What attackers can read

The disclosed impact is confidentiality, not code execution. But the leaked files are often the exact files that turn a dev-server bug into a real incident:

  • .env
  • .env.local
  • .env.development
  • *.crt
  • *.pem

In modern frontend and full-stack repos, those files commonly hold:

  • API keys used for local integrations
  • third-party service credentials
  • dev-only JWT or session secrets
  • TLS key material for local HTTPS testing
  • internal hostnames and connection strings

That makes this more than a harmless dev quirk. A network-reachable dev server can become a low-friction way to extract secrets from a developer or QA host.

Detection and scoping

Start by finding Vite installations and Windows-exposed server configs:

npm ls vite vite-plus
rg -n "server\\.host|host:\\s*true|--host|server\\.fs\\.allow|server\\.fs\\.deny" .

Then identify whether sensitive files live under allowed directories:

rg -n "^" .env .env.* "*.pem" "*.crt"

Review whether any Windows-hosted dev servers were exposed to untrusted users or networks. The most relevant evidence sources are:

  • shell history or scripts that launch vite --host
  • Vite config files with server.host enabled
  • reverse-proxy or tunnel configs pointing at Vite’s dev port
  • Windows hosts where project secrets stayed under the served working tree

Remediation

Upgrade to a patched release immediately:

npm install vite@^8.0.16
# or
npm install vite@^7.3.5
# or
npm install vite@^6.4.3

If vite is transitive, upgrade the parent framework or use the repository’s normal override mechanism until upstream packages catch up.

Hardening before and after patching

Even after upgrading, treat this as a reminder that dev servers are not secret stores.

  • Keep Vite dev servers bound to localhost unless remote access is absolutely required.
  • Move .env, .pem, and .crt material outside the served project tree where practical.
  • Avoid broad server.fs.allow entries that pull secret-bearing directories into the served set.
  • Do not assume a filename-based deny list is a substitute for network isolation.

Why this matters beyond Vite

CVE-2026-53571 is not a novel browser exploit. It is a pathname-normalization failure in development infrastructure. Those bugs are easy to underestimate because they show up in tools teams think of as local-only, ephemeral, or low risk.

But once a dev server is reachable over the network, its path-filtering logic becomes part of your security perimeter. In this case, the attack did not need code execution, social engineering, or a dependency compromise. It only needed a Windows path variant that the deny check forgot to normalize.

References