Cloudanix VulnDB

CVE-2025-62522

None

CVSS

—

EPSS

1.1%

Published

Oct 20, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Exposed Windows-based Vite development servers may let outsiders download sensitive project files that should have been blocked.

Weaponized
Exploitation
Requires User Interaction
Attacker needs
None
Complexity
Moderate
Impact
Data Exposure
Component
Web Framework
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This is an information disclosure flaw in the Vite development server on Windows. When the dev server is exposed to a network, requests for files that should be blocked by the server.fs.deny policy can bypass that deny rule if the requested URL ends with a backslash character. The issue affects Vite versions 2.9.18 to before 3.0.0, 3.2.9 to before 4.0.0, 4.5.3 to before 5.0.0, 5.2.6 to before 5.4.21, 6.0.0 to before 6.4.1, 7.0.0 to before 7.0.8, and 7.1.0 to before 7.1.11. The practical impact is unauthorized read access to sensitive local project files that Vite is configured to deny, such as environment files, certificates, keys, source metadata, or other development artifacts. The flaw does not directly provide code execution, file modification, or service disruption, but exposed secrets can enable follow-on compromise of source repositories, cloud services, package registries, APIs, or internal systems.

Why it matters to the business

Organizations that expose Vite development servers from Windows workstations, build hosts, demo systems, or shared development environments risk leakage of sensitive development files. The highest-impact outcome is disclosure of secrets such as API tokens, cloud credentials, OAuth secrets, database connection strings, private keys, or proprietary source information. Because exploit maturity is reported as weaponized, security teams should treat internet- or intranet-exposed Vite dev servers as urgent even though this is not currently listed in CISA KEV and EPSS is low at 0.01016. The risk is narrower than a typical production web server vulnerability because only Windows-hosted Vite dev servers intentionally exposed to the network are affected, but compromise of development secrets can still lead to production data access, supply-chain abuse, unauthorized deployments, or costly credential rotation.

How an attack unfolds

An attacker first identifies a reachable Vite development server, commonly by probing for Vite-specific responses, HMR endpoints, JavaScript module paths, or default dev server ports such as 5173. The vulnerable condition requires the server to be running on Windows and exposed beyond localhost. The attacker then requests files normally protected by Vite's server.fs.deny controls and appends a trailing backslash, or an encoded backslash, to the URL. On vulnerable versions, path handling on Windows can cause the deny check to be bypassed and the file content to be returned. The attacker iterates over high-value targets such as .env files, private keys, certificate files, package manager credentials, source control metadata, and configuration files. Any recovered credentials are then tested against external services, source repositories, cloud control planes, CI/CD systems, package registries, or application backends for lateral movement or data access.

How to fix it

Upgrade Vite to a fixed version for the active major line: 5.4.21 or later, 6.4.1 or later, 7.0.8 or later, or 7.1.11 or later. The upstream Git fix is commit 8b69c9e32c3606ae375a1333cd38e91848d27781. For older affected branches, upgrade to a supported fixed release rather than relying on configuration-only mitigations. Do not expose Vite development servers to untrusted networks; bind dev servers to localhost by default, restrict access with firewall rules or VPN, and avoid running them on shared or internet-facing Windows hosts. If temporary exposure is unavoidable, place the service behind authentication and network allowlisting, and explicitly verify that server.fs.deny protects sensitive files. Remove secrets from project working directories where possible, use environment-specific secret stores, and rotate any credentials that may have been accessible from exposed dev servers.

How to confirm the fix worked

Confirm the installed Vite version is not in an affected range by checking package manifests and lockfiles, for example package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, or bun.lockb. Validate that all reachable dev servers are running Vite 5.4.21+, 6.4.1+, 7.0.8+, 7.1.11+, or another build containing upstream commit 8b69c9e32c3606ae375a1333cd38e91848d27781. Confirm dev servers are not bound to 0.0.0.0 or externally reachable unless access is intentionally restricted. From an authorized test system, attempt to fetch known denied files with a trailing backslash and URL-encoded backslash; a fixed or properly protected server should not return file contents. Also validate that firewall rules, reverse proxies, and endpoint controls prevent untrusted access to Vite dev server ports.

Typical attack path

  1. Scan for Vite development servers exposed on the internet or internal network, especially default ports such as 5173.
  2. Fingerprint the service using Vite-specific responses, HMR/WebSocket behavior, module import paths, or dev server headers/errors.
  3. Confirm likely Windows hosting by testing Windows-style path behavior or observing responses to backslash-terminated file requests.
  4. Request sensitive files that are normally blocked by server.fs.deny, appending a literal trailing backslash or URL-encoded backslash.
  5. Review returned file contents for secrets, source code, certificates, tokens, package registry credentials, or cloud configuration.
  6. Use exposed credentials or internal knowledge for follow-on access to repositories, CI/CD systems, cloud services, APIs, or application infrastructure.
  7. Cover tracks by blending requests into normal development traffic or using common scanner user agents and distributed source IPs.

How to detect it

Investigate whether any affected Vite dev server was reachable from untrusted networks while running on Windows. Review Vite dev server console output, terminal scrollback, reverse proxy logs, web server access logs, EDR network telemetry, firewall flow logs, and packet captures for HTTP requests containing sensitive file names combined with a trailing backslash or encoded backslash. Focus on requests to Vite-specific file-serving paths such as /@fs/ and paths attempting to access .env files, source control directories, package manager credential files, private keys, certificate files, or project configuration files. Look for response status codes indicating success, unusually large responses for normally denied files, repeated enumeration of sensitive filenames, requests from unfamiliar IP addresses, and user agents associated with scanners. If logs show successful responses to sensitive-file probes, perform secret exposure handling: preserve logs, identify exactly what files may have been returned, rotate all potentially exposed credentials, review downstream access logs for use of those credentials, and check source repositories, CI/CD platforms, cloud audit logs, package registries, and application APIs for suspicious activity after the first exposure time.

  • GET /@fs/
  • /@fs/C:/
  • .env\
  • .env%5c
  • .env%5C
  • .env.local\
  • .env.local%5c
  • .env.local%5C
  • .env.development\
  • .env.development%5c
  • .env.development%5C
  • .env.production\
  • .env.production%5c
  • .env.production%5C
  • .git\
  • .git%5c
  • .git%5C
  • .git/config\
  • .git/config%5c
  • .git/config%5C
  • .npmrc\
  • .npmrc%5c
  • .npmrc%5C
  • .yarnrc\
  • .yarnrc%5c
  • .yarnrc%5C
  • .pypirc\
  • .pypirc%5c
  • .pypirc%5C
  • id_rsa\
  • id_rsa%5c
  • id_rsa%5C
  • .pem\
  • .pem%5c
  • .pem%5C
  • .key\
  • .key%5c
  • .key%5C
  • .crt\
  • .crt%5c
  • .crt%5C
  • server.fs.deny
  • vite --host 0.0.0.0
  • Local: http://localhost:5173/
  • Network: http://

What your security team should do

  • Inventory Vite usage across development workstations, build hosts, containers, demo environments, and internal tooling; prioritize any Windows-hosted dev servers reachable over the network.
  • Immediately remove public or broad network exposure for Vite dev servers, especially those bound to 0.0.0.0 or running on default port 5173.
  • Upgrade affected projects to Vite 5.4.21+, 6.4.1+, 7.0.8+, or 7.1.11+ as applicable, or to a later supported major version.
  • Search web access logs, reverse proxy logs, endpoint telemetry, and dev server console logs for denied-file probes using trailing backslashes or encoded backslashes.
  • Rotate secrets found in project directories on any Vite dev server that was exposed while running an affected version, with priority for .env files, private keys, cloud tokens, package registry tokens, and CI/CD credentials.
  • Add detections for requests targeting sensitive filenames with literal or encoded trailing backslashes, including .env, .git, .npmrc, .pypirc, id_rsa, .pem, .key, and certificate files.
  • Update developer guidance to prohibit exposing frontend dev servers directly to the internet and to require localhost binding or authenticated network access for shared testing.

The record

Vite is a frontend tooling framework for JavaScript. In versions from 2.9.18 to before 3.0.0, 3.2.9 to before 4.0.0, 4.5.3 to before 5.0.0, 5.2.6 to before 5.4.21, 6.0.0 to before 6.4.1, 7.0.0 to before 7.0.8, and 7.1.0 to before 7.1.11, files denied by server.fs.deny were sent if the URL ended with \ when the dev server is running on Windows. Only apps explicitly exposing the Vite dev server to the network and running the dev server on Windows were affected. This issue has been patched in versions 5.4.21, 6.4.1, 7.0.8, and 7.1.11.

Affected packages

Ecosystem Package Introduced Fixed
npm vite 2.9.18 5.4.21
npm vite 3.2.9 5.4.21
npm vite 4.5.3 5.4.21
npm vite 5.2.6 5.4.21
npm vite 6.0.0 6.4.1
npm vite 7.0.0 7.0.8
npm vite 7.1.0 7.1.11
Chainguard langfuse 0 3.121.0-r0
Chainguard langfuse-compat 0 3.121.0-r0
Chainguard langfuse-worker 0 3.121.0-r0
Chainguard librechat 0 0.8.0-r2
Chainguard librechat-compat 0 0.8.0-r2
Chainguard librechat-dev 0 0.8.0-r2
Chainguard renovate 0 41.156.1-r0
Chainguard vitess-20 0 0
Chainguard vitess-20-binaries 0 0
Chainguard vitess-20-compat 0 0
Chainguard vitess-21 0 0
Chainguard vitess-21-binaries 0 0
Chainguard vitess-21-compat 0 0
Chainguard vitess-22 0 0
Chainguard vitess-22-binaries 0 0
Chainguard vitess-22-compat 0 0
Chainguard vitess-23 0 0
Chainguard vitess-23-binaries 0 0
Chainguard vitess-23-compat 0 0
Wolfi langfuse 0 3.121.0-r0
Wolfi langfuse-compat 0 3.121.0-r0
Wolfi langfuse-worker 0 3.121.0-r0
Wolfi renovate 0 41.156.1-r0
Wolfi vitess-20 0 0
Wolfi vitess-20-binaries 0 0
Wolfi vitess-20-compat 0 0
Wolfi vitess-21 0 0
Wolfi vitess-21-binaries 0 0
Wolfi vitess-21-compat 0 0
Wolfi vitess-22 0 0
Wolfi vitess-22-binaries 0 0
Wolfi vitess-22-compat 0 0
Wolfi vitess-23 0 0
Wolfi vitess-23-binaries 0 0
Wolfi vitess-23-compat 0 0

Related vulnerabilities