CVE-2025-30208

This vulnerability lets someone “get around the do-not-open list” in Vite. Even if your settings say certain files must stay blocked, a specific kind of request can sometimes retrieve them. It’s like putting a lock on a cabinet and then finding a shortcut that opens it from the back door.

This matters if you run Vite (for example, a web app’s Vite dev server or any internal service built with Vite) and you have file blocking enabled using server.fs.deny to protect sensitive folders. It’s mainly a risk when an attacker can reach your Vite server over the network and then trigger a victim to open a crafted URL (user interaction is required). If your Vite server isn’t reachable from untrusted users, the risk is much lower.

This is RED because attackers can retrieve files that Vite is supposed to block, and there are signs of active exploitation in the wild (sustained press attention). Since it’s network-triggered and involves a user interacting with a crafted link, assume real attempts can reach your users if your Vite server is exposed.

Confirm exposure

• Identify whether your business uses Vite and where it runs (developer workstation only, CI only, internal web app, or any dev server exposed to users).
• Locate the Vite version used by your app (e.g., from your package.json and installed node_modules/vite). Treat anything older than 6.2.3 as potentially vulnerable.
• Check whether you use server.fs.deny (custom blocking rules for file paths).

Determine the fixed version(s)

Upgrade to the fixed Vite release:

• Fixed in: vite 6.2.3
• The remediation also indicates the fix is present in versions at or above the listed thresholds (depending on your branch), but the clear instruction for upgrades is 6.2.3.

Upgrade plan

• Schedule the upgrade for the next maintenance window, but prioritize if your Vite server is reachable by users or exists in any environment where an attacker can induce clicks.
• Upgrade Vite and restart the service.
• After upgrade, test your dev workflow and run any existing security/functional checks.

Temporary workaround (if you can’t upgrade immediately)

• Do not expose the Vite dev server to untrusted networks/users.
• Restrict access with network controls (IP allowlists, VPN-only access, or internal-only routing).
• Remove or restrict endpoints/routes that could cause user interaction with attacker-provided URLs.

What to monitor

• Web server and application logs for unusual requests containing raw-style query parameters (the pattern involved in this issue).
• Attempts to access paths that should be denied (look for requests that correlate with “denied” directories in your Vite configuration).

CISA due date

• Not provided in the findings (KEV not listed).

Severity is assessed as medium by the provided scoring, but it is treated as high priority for small businesses due to active exploitation signals. The weakness is a bypass of server.fs.deny (CWE-200/CWE-284 category) in Vite: a specific ?raw??-style request can cause Vite to read and return files that should be blocked by the server-side deny rules. Attack vector is network, no authentication required, but user interaction is required (victim must trigger the crafted request). A public proof-of-concept exists, and sustained press attention indicates exploitation activity; KEV listing was not present in the provided findings. A predicted exploitation likelihood exists, but it is not used as a deciding factor here because exploitation signals take precedence.