CVE-2025-58752

What it actually does

This flaw affects Vite development servers. The server-side file access controls configured through `server.fs` could be bypassed for HTML files, causing HTML files present on the host to be served even when they were outside the intended allowed filesystem scope. The impact is information disclosure: an unauthenticated network user who can reach the Vite dev server may be able to retrieve local HTML files that were not meant to be exposed. The issue does not directly provide code execution, privilege escalation, or write access, but disclosed HTML may contain sensitive application structure, embedded tokens, internal URLs, test fixtures, prototype pages, comments, or references to other private resources.

Why it matters to the business

If a Vite dev server is reachable from untrusted networks, an attacker may be able to view local HTML files that developers or build systems assumed were private. This can expose unreleased application content, internal implementation details, credentials accidentally embedded in HTML, or information useful for follow-on attacks. The current public exploitation signal is low: EPSS is 0.00586, it is not listed in CISA KEV, no ransomware use is indicated, and exploit maturity is reported as none. However, because Vite is commonly used in development workflows, accidental internet exposure of dev servers remains the main operational risk.

How an attack unfolds

An attacker first identifies a reachable Vite development server, typically by probing common development ports or recognizing Vite-specific responses. They then send crafted HTTP requests for HTML resources that should be blocked by the configured `server.fs` restrictions. Due to the bypass, the dev server may process and return HTML files from locations outside the intended project root or allowlist. The attacker reviews returned HTML for secrets, internal routes, references to source files, API endpoints, comments, build metadata, or links to other sensitive files. If useful information is found, it may be used to target the application, developers, CI/CD systems, or internal services through separate attack paths.

How to fix it

Upgrade Vite to a version that includes the upstream fix. For source-based deployments or pinned Git dependencies, ensure the Vite dependency includes commit `997700f01c7199daf7330d33a7fd3a43b2e9e3ba` or a later release containing that fix. Remove duplicate or stale lockfile entries and rebuild dependent applications so the patched Vite version is actually used. As defense in depth, do not expose Vite development servers to the public internet; bind dev servers to localhost where possible, place them behind authentication if remote access is required, restrict access with firewall or VPN controls, and avoid storing secrets or sensitive internal documentation in HTML files accessible to development tooling.

How to confirm the fix worked

Confirm the installed Vite package or Git revision includes commit `997700f01c7199daf7330d33a7fd3a43b2e9e3ba` or a later fixed version. Review package lockfiles and dependency trees to ensure no vulnerable Vite copy remains. Start a test Vite dev server with restrictive `server.fs` settings and attempt to request an HTML file outside the allowed directory; the expected fixed behavior is denial rather than serving the file. Externally validate that Vite dev-server ports are not reachable from untrusted networks. Review reverse proxy, firewall, and cloud security group rules to confirm development services are not publicly exposed.

Typical attack path

1. Discover a network-accessible Vite development server.
2. Confirm the service is a Vite dev server by observing response headers, error pages, module paths, or dev-server behavior.
3. Request HTML files using paths that should fall outside the configured filesystem allowlist or project root.
4. Use URL encoding, absolute-file-serving paths, or path variations to test whether `server.fs` restrictions are being bypassed for `.html` content.
5. Review any returned HTML for sensitive information such as embedded credentials, internal hostnames, unreleased pages, comments, source references, or API endpoints.
6. Use the disclosed information to support phishing, source-code discovery, application probing, or targeted attacks against related systems.

How to detect it

To assess prior exploitation, review HTTP access logs from Vite dev servers, reverse proxies, load balancers, endpoint web logs, and container ingress logs. Focus on requests for `.html` files outside expected application routes, especially requests containing Vite file-serving paths such as `/@fs/`, absolute filesystem paths, path traversal sequences, URL-encoded traversal, or unusual references to developer directories. Look for successful 200 responses with nontrivial response sizes to suspicious `.html` requests. Correlate source IPs that performed broad probing, repeated 404/403/200 sequences, or requests across multiple filesystem-looking paths. Endpoint telemetry may show Vite processes bound to non-localhost interfaces or receiving unexpected inbound connections. Because this is an information disclosure issue, exploitation may leave only web access traces and may not create files, processes, registry keys, or malware artifacts.

• GET /@fs/
• POST /@fs/
• /@fs/
• ..%2f
• %2e%2e%2f
• ../
• ..\\
• %2e%2e%5c
• .html HTTP/1.1
• /etc/passwd
• /etc/hosts
• /Users/
• /home/
• C:/Users/
• C:\\Users\\
• vite --host
• Vite dev server

What your security team should do

• Inventory exposed Vite development servers and prioritize any reachable from the internet or shared networks.
• Upgrade all Vite dependencies to a fixed version containing commit `997700f01c7199daf7330d33a7fd3a43b2e9e3ba` or later.
• Audit package lockfiles, monorepos, templates, and container images for embedded vulnerable Vite versions.
• Restrict Vite dev servers to localhost or trusted administrative networks; require VPN or authentication for remote development access.
• Search HTTP access logs for requests using Vite absolute file-serving paths, traversal patterns, encoded traversal, and unexpected `.html` file retrievals.
• Review disclosed or potentially retrievable HTML files for embedded credentials, internal hostnames, API keys, access tokens, comments, or sensitive business information.
• Add CI/CD or dependency-scanning controls to flag vulnerable Vite versions before deployment.
• Treat this as lower urgency than actively exploited KEV issues, but remediate promptly where dev servers are externally reachable.