CVE-2025-46565

What it actually does

CVE-2025-46565 is a file exposure/path traversal class flaw in Vite's development server file-serving logic. Files located under the configured Vite project root that should be blocked by deny-list file matching rules can still be returned to a browser under certain request patterns. The practical technical impact is unauthorized read access to source-tree files that the application operator expected Vite to withhold, such as environment files, local configuration, private keys, tokens, or other development artifacts if those files exist inside the project root and the dev server is reachable.

Why it matters to the business

If a vulnerable Vite development server is exposed beyond a trusted local developer workstation or CI environment, attackers may be able to retrieve sensitive project files and use them to steal credentials, access downstream services, inspect source code, or support further compromise. The issue is not currently listed in CISA KEV and has a low EPSS score, but exploit maturity is reported as weaponized and the vulnerability has been public for a long period, so internet-exposed or shared development servers should be treated as urgent. Organizations with many JavaScript applications or build pipelines using Vite should assume broad inventory work may be needed.

How an attack unfolds

An attacker first identifies a reachable Vite development server, typically by its response headers, HTML, module loading behavior, or Vite-specific endpoints. The attacker then sends crafted HTTP requests for files under the Vite project root that are normally protected by Vite deny patterns. By using the vulnerable request form, the attacker bypasses the intended deny check and causes the server to return file contents to the browser. The attacker prioritizes high-value files such as .env variants, local configuration files, package metadata, certificates, keys, and source files. Any recovered secrets can then be reused against package registries, cloud APIs, databases, source repositories, CI/CD systems, or application backends.

How to fix it

Upgrade Vite to a version that includes the upstream fix, or if consuming directly from Git, update to a revision containing commit b040d547a17c4bfe8aba44534228667a50612318. Remove duplicate or pinned vulnerable Vite references from lockfiles and monorepos, then rebuild affected development images and CI containers. Do not expose Vite development servers to the public internet; bind dev servers to localhost where possible, place them behind authentication/VPN if remote access is unavoidable, and block inbound access at firewalls and security groups. Treat Vite's dev server as a development tool rather than a production file server. Move secrets out of the project root where feasible, avoid storing long-lived credentials in .env files, and rotate any secrets that may have been accessible through an exposed vulnerable instance.

How to confirm the fix worked

Confirm dependency and runtime versions by inspecting package manifests, lockfiles, container images, and deployed development environments for Vite builds that do not include commit b040d547a17c4bfe8aba44534228667a50612318. Validate that Vite development servers are not reachable from untrusted networks by scanning externally and internally for default Vite ports such as 5173 and for Vite-specific responses. After upgrading, perform controlled requests for representative denied files inside a test project root, such as .env, .env.local, certificate files, and other entries covered by server.fs.deny; the server should refuse access and must not return file contents. Confirm that firewall, reverse proxy, and local binding settings prevent unauthenticated remote access to development servers.

Typical attack path

1. Scan for exposed Vite development servers or applications showing Vite-specific behavior.
2. Fingerprint the server to confirm it is using an affected Vite build or commit range.
3. Request files inside the configured project root that are commonly protected by deny rules, such as environment and configuration files.
4. Use the vulnerable path/request pattern to bypass Vite's file deny matching and retrieve file contents.
5. Extract credentials, API keys, internal URLs, source code, package metadata, or deployment configuration from the exposed files.
6. Use recovered secrets or knowledge to access downstream services, move laterally, or prepare more targeted attacks.

How to detect it

To determine whether this was already exploited, review HTTP access logs from Vite dev servers, reverse proxies, WAFs, load balancers, VPN gateways, developer tunnel services, and any CDN or ingress layer in front of development or preview environments. Focus on requests to Vite-specific file-serving paths and requests for files commonly protected by deny rules, especially .env, .env.local, .env.production, private keys, certificates, package metadata, source maps, and configuration files. Look for successful 200 responses with non-trivial response sizes for files that should never be served to browsers. Investigate repeated 403/404/200 sequences where an actor probes multiple encodings or path variants, as this can indicate bypass attempts. Correlate suspicious requests with source IPs, user agents, developer tunnel URLs, unusual geographies, and subsequent authentication events against cloud, database, source control, package registry, or CI/CD services using credentials that may have been exposed. On affected hosts or containers, preserve Vite process logs, shell history, reverse proxy logs, and filesystem timestamps for sensitive files under project roots. If sensitive files were returned or if logs are incomplete, assume exposed secrets are compromised and rotate them.

• GET /.env
• GET /.env.local
• GET /.env.development
• GET /.env.production
• GET /.env.test
• GET /@fs/
• /@fs/
• ?raw
• .env?raw
• .env.local?raw
• .env.production?raw
• GET /vite.config.js
• GET /vite.config.ts
• GET /package.json
• GET /pnpm-lock.yaml
• GET /yarn.lock
• GET /package-lock.json
• GET /id_rsa
• GET /id_ed25519
• GET /server.key
• GET /server.pem
• GET /cert.pem
• GET /config.json
• GET /config.yaml
• GET /config.yml
• GET /secrets.json
• GET /.npmrc
• GET /.pypirc
• GET /.git/config
• Vite development server
• vite --host 0.0.0.0
• Local: http://localhost:5173/
• Network: http://

What your security team should do

• Inventory repositories, developer workstations, CI jobs, preview environments, and containers that use Vite, prioritizing instances reachable from networks other than localhost.
• Patch or rebuild all affected Vite installations to include commit b040d547a17c4bfe8aba44534228667a50612318 or a released version containing that fix.
• Immediately restrict network access to Vite development servers; block public exposure and require VPN or authenticated access for shared dev environments.
• Search historical web, proxy, CDN, WAF, and Vite server logs for suspicious requests targeting .env files, configuration files, keys, or Vite file-serving endpoints.
• Rotate secrets stored under project roots on any system where a vulnerable Vite server was reachable by untrusted users.
• Add CI checks to prevent long-lived secrets from being committed under web project roots and to flag vulnerable Vite versions in package lockfiles.
• Document that Vite dev servers must not be used as production servers or exposed without compensating controls.