CVE-2025-31125

What it actually does

This vulnerability is an information disclosure flaw in Vite caused by improper access control around file-serving behavior. A remote attacker who can reach an affected Vite development server may send crafted HTTP requests that cause the server to return the contents of arbitrary local files that the Vite process can read. Impact is limited to confidentiality by itself, but the exposed data can include source code, environment files, dependency manifests, configuration files, credentials, tokens, private keys, internal endpoints, and other secrets that can enable follow-on compromise.

Why it matters to the business

If an affected Vite server is reachable by untrusted users, attackers may be able to steal sensitive application and infrastructure data without needing authentication. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has a high EPSS probability, internet-exposed development servers should be treated as urgent. The business risk is highest where Vite dev servers are exposed beyond localhost or trusted networks, because leaked secrets can lead to account takeover, cloud resource abuse, source-code exposure, customer data access through downstream systems, or disruption from emergency credential rotation. CISA’s KEV remediation due date is 2026-02-12.

How an attack unfolds

An attacker first identifies a reachable Vite development server, commonly by probing for Vite-specific client, module, or hot-reload endpoints. The attacker then sends crafted requests that abuse Vite’s file-serving routes or path normalization behavior to request files outside the intended served project scope. If the server is vulnerable, it responds with raw file contents in the browser or HTTP response body. The attacker typically starts with harmless validation targets such as package manifests or configuration files, then attempts higher-value files such as .env files, Vite configuration, source code, shell history, SSH material, cloud credentials, process environment data, and operating-system files. Stolen secrets may then be used to access code repositories, CI/CD systems, cloud APIs, databases, or production services. Current reporting indicates active exploitation in the wild; no ransomware-specific KEV association is indicated in the supplied data.

How to fix it

Upgrade Vite to a version that includes the upstream fix, or build from a commit at or after 037f801075ec35bb6e52145d659f71a23813c48f for vitejs/vite. Remove duplicate or pinned transitive references that keep vulnerable Vite code in use. As an immediate mitigation, do not expose Vite development servers to the internet or untrusted networks; bind the dev server to localhost where possible, restrict access with firewall/VPN controls, and avoid running development servers in production-like environments. Review Vite server filesystem settings, including allowed and denied paths, but do not rely on configuration-only mitigations where a patched version is available. Rotate any secrets that may have been accessible to the Vite process if exposure is suspected, especially .env values, API tokens, SSH keys, cloud credentials, and CI/CD secrets.

How to confirm the fix worked

Confirm the installed Vite source includes fix commit 037f801075ec35bb6e52145d659f71a23813c48f or a packaged release containing that change. Use dependency inventory tooling such as npm, pnpm, yarn, lockfile review, SBOMs, and container image scans to locate all Vite installations, including development containers and build images. Verify that Vite development servers are not reachable from untrusted networks by checking listening interfaces, reverse proxy routes, firewall rules, and external network scans. After patching, perform controlled negative testing against previously vulnerable file-read request patterns and confirm sensitive local files are not returned. Confirm no vulnerable Vite process remains running from an old build after dependency updates by restarting dev servers, containers, and build agents.

Typical attack path

1. Scan the internet or internal address space for exposed Vite development servers and Vite-specific responses.
2. Confirm the target is running an affected Vite build by requesting common Vite development endpoints or static module paths.
3. Send crafted HTTP GET requests designed to bypass intended filesystem access controls and retrieve local files.
4. Read low-risk files first to validate the issue, such as dependency manifests or Vite configuration files.
5. Request sensitive files such as .env, source files, private keys, process environment data, or user configuration files accessible to the Vite process.
6. Extract credentials, tokens, internal URLs, or application secrets from the returned content.
7. Use the exposed secrets for follow-on access to source repositories, CI/CD platforms, cloud services, databases, or application environments.

How to detect it

Review HTTP access logs from reverse proxies, load balancers, WAFs, web servers, container ingress controllers, and any process-level Vite logs for requests that combine Vite-specific routes with filesystem paths, traversal sequences, encoded traversal, or sensitive filenames. Focus on GET requests to Vite development endpoints such as /@fs/ and module import URLs that reference files outside the expected project tree. Look for successful 200 responses with unusually large response sizes or response sizes consistent with sensitive files after requests for .env, package manifests, SSH keys, /etc/passwd, /proc/self/environ, cloud credential paths, or application configuration files. Correlate suspicious requests with source IPs that performed prior scanning for Vite endpoints such as /@vite/client. In host forensics, review shell history, process command lines, container logs, and file access telemetry for exposed Vite dev server processes, but note that exploitation may leave no local file modification because the primary action is read-only HTTP disclosure. If exploitation is suspected, preserve web/proxy logs, container stdout/stderr, Vite process logs, and network flow records before rotation or cleanup.

• GET /@fs/
• /@fs/
• /@vite/client
• ?raw
• ?import
• ../
• ..%2f
• %2e%2e%2f
• %252e%252e%252f
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• /proc/self/cmdline
• .env
• .env.local
• .env.production
• vite.config.js
• vite.config.ts
• package.json
• pnpm-lock.yaml
• yarn.lock
• package-lock.json
• id_rsa
• id_ed25519
• .ssh/
• /root/.ssh/
• /home/
• credentials.json
• .aws/credentials
• .npmrc
• .yarnrc

What your security team should do

• Prioritize internet-exposed or remotely reachable Vite development servers because the vulnerability is in CISA KEV and is actively exploited in the wild.
• Upgrade all affected vitejs/vite instances to a fixed build that includes commit 037f801075ec35bb6e52145d659f71a23813c48f or later.
• Immediately restrict Vite dev server exposure to localhost, VPN-only, or trusted administrative networks; block public access at firewalls and reverse proxies.
• Search access logs and proxy logs for file-read attempts against Vite-specific endpoints and sensitive filenames.
• Inventory repositories, containers, CI images, developer workstations, and ephemeral build environments for vulnerable Vite usage.
• If suspicious requests are found, assume files readable by the Vite process may have been disclosed and rotate exposed application, cloud, repository, and CI/CD secrets.
• Add SIEM detections for Vite file-serving paths combined with traversal sequences, encoded traversal, and sensitive file names.
• Ensure Vite development servers are not used as production hosting mechanisms; deploy production builds behind hardened web servers instead.