CVE-2025-31486

What it actually does

A path traversal and file disclosure vulnerability in the Vite development server allows an unauthenticated remote attacker to bypass the `server.fs.deny` security restriction. By crafting a malicious HTTP request with specific query parameters (e.g., `?.svg` with `?.wasm?init`) or a `sec-fetch-dest: script` header, an attacker can read the contents of arbitrary files from the server's filesystem. The vulnerability is limited to files smaller than the `build.assetsInlineLimit` configuration (defaulting to 4KB) and only affects Vite development servers explicitly configured to be accessible over the network.

Why it matters to the business

Exploitation of this vulnerability can lead to the exfiltration of sensitive information from development environments. This includes application source code, configuration files containing API keys and database credentials, and other intellectual property. The leakage of such data can result in further system compromise, financial loss, reputational damage, and potential regulatory penalties. The risk is heightened for organizations that expose development or staging servers to the internet for testing or collaboration purposes, as this flaw is actively and easily exploited in the wild.

How an attack unfolds

An attacker first identifies a Vite development server exposed to the internet, often using automated scanners or public search engines like Shodan. The attacker then crafts a URL to request a sensitive file they believe exists on the server, such as `.env` or a configuration file. To bypass the server's file system access controls, they append a special string like `?.svg&..&.wasm?init` to the file path in the URL. When the vulnerable Vite server receives this request, it incorrectly processes the path, bypassing the deny list. If the requested file is smaller than 4KB, the server returns its contents to the attacker, compromising the confidentiality of the data.

How to fix it

The primary remediation is to upgrade Vite to a patched version. Update your project's dependencies to use Vite version 4.5.12, 5.4.17, 6.0.14, 6.1.4, 6.2.5, or newer. As a critical security best practice, avoid exposing development servers to the public internet. Configure the Vite server to only listen on localhost. If network access is required, restrict it to trusted IP addresses using a firewall, VPN, or an authentication proxy.

How to confirm the fix worked

To confirm remediation, inspect your project's lock file (`package-lock.json`, `yarn.lock`) or run `npm list vite` to ensure the installed version is one of the patched versions or later. To test for the vulnerability, you can attempt to access a known file from an external network using a proof-of-concept URL (e.g., `http://<your-server>/package.json?.svg?.wasm?init`). A patched or properly firewalled server should return a 403 Forbidden or connection error, while a vulnerable server will return the file's contents.

Typical attack path

1. An attacker scans public IP ranges to discover exposed Vite development servers.
2. The attacker identifies a target server and guesses the path to a sensitive file (e.g., `.env`, `src/secrets.js`).
3. A malicious HTTP GET request is sent to the server, with the path to the sensitive file appended with a bypass sequence like `?.svg?.wasm?init`.
4. The vulnerable Vite server processes the request, bypasses the `server.fs.deny` protection, and reads the file from disk.
5. The server sends the file's contents back to the attacker in the HTTP response.
6. The attacker uses the exfiltrated credentials or source code to mount further attacks against the organization's infrastructure.

How to detect it

To detect exploitation attempts, security teams should review HTTP access logs for any internet-facing Vite development servers. Look for GET requests containing unusual URL patterns, specifically the presence of `?.svg` followed by query strings containing `..` or `.wasm?init`. Another indicator is a request for a non-script file (e.g., `.json`, `.txt`, `.env`) that includes the HTTP header `Sec-Fetch-Dest: script`. Successful exploitation will likely result in a 200 OK status code, while a 403 or 404 may indicate a failed attempt.

• ?.svg&..&.wasm?init
• ?.svg?.wasm?init
• GET /*?.svg* HTTP/1.1

What your security team should do

• Immediately upgrade all Vite instances to a patched version (4.5.12+, 5.4.17+, 6.0.14+, 6.1.4+, 6.2.5+), as this vulnerability has weaponized exploits available.
• Scan your organization's public IP space to identify and inventory any exposed Vite development servers.
• Enforce a strict policy against exposing development servers to the internet. Mandate the use of VPNs or IP-based access controls for any required remote access.
• Review web server and reverse proxy logs for requests matching the patterns described in the detection guidance to identify past exploitation attempts.