CVE-2026-39364

What it actually does

CVE-2026-39364 is an information disclosure flaw in the Vite development server. In affected Vite versions, files intended to be blocked by the server.fs.deny configuration, such as .env files, certificates, keys, and other sensitive project files, can be retrieved when certain Vite query parameters are appended to the request path, including ?raw, ?import&raw, or ?import&url&inline. The issue does not require authentication or user interaction when the dev server is network-reachable. The primary technical consequence is unauthorized read access to files that should have been denied by Vite’s file-serving protections.

Why it matters to the business

If a vulnerable Vite dev server is exposed to an untrusted network, an attacker may be able to download sensitive development files such as environment variables, API keys, private certificates, database credentials, or cloud tokens. This can lead to account takeover, unauthorized access to internal or third-party services, source code and secret leakage, and downstream compromise of build, cloud, or application environments. Although Vite dev servers are commonly intended for local development, accidental exposure in containers, remote development workspaces, CI systems, shared lab environments, or internet-facing preview environments can turn this into a high-impact credential exposure issue. The exploit is reported as weaponized, increasing remediation urgency even though it is not currently listed in CISA KEV and has a modest EPSS score.

How an attack unfolds

An attacker first identifies a reachable Vite development server, often by scanning for typical Vite ports, Vite response headers, dev-client paths, or frontend assets served by the dev server. The attacker then probes for sensitive files that are normally protected by server.fs.deny, such as /.env, /.env.local, certificate files, or key material. Instead of requesting the file directly, the attacker appends Vite-specific query parameters such as ?raw, ?import&raw, or ?import&url&inline. On vulnerable versions, the dev server incorrectly returns HTTP 200 and discloses the file contents. The attacker extracts secrets from the response and uses them for follow-on access, such as authenticating to cloud accounts, databases, package registries, SaaS APIs, or internal services. Successful exploitation may leave only HTTP access-log evidence unless the exposed credentials are later used elsewhere.

How to fix it

Upgrade Vite to a fixed version immediately. For Vite 7.x, upgrade to 7.3.2 or later. For Vite 8.x, upgrade to 8.0.5 or later. Check direct and transitive dependencies in package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lockb, and workspace manifests to ensure vulnerable Vite versions are not retained. Rebuild and redeploy development containers or remote workspace images that include Vite. Do not expose the Vite dev server to the internet or untrusted networks; bind it to localhost where possible, place it behind authenticated access if remote development is required, and restrict inbound access by firewall or VPN. Treat any exposed .env, certificate, token, or key material as potentially compromised and rotate affected secrets. As a defense-in-depth measure, avoid storing production secrets in frontend project directories and use secret-management tooling rather than local plaintext files where possible.

How to confirm the fix worked

Confirm the installed Vite version with package-manager commands such as npm ls vite, pnpm why vite, yarn why vite, or bun pm ls, and verify that all resolved versions are 7.3.2 or later for the 7.x line or 8.0.5 or later for the 8.x line. Inspect lockfiles to ensure vulnerable versions from 7.1.0 through versions before 7.3.2, and affected 8.x versions before 8.0.5, are no longer present. Validate network exposure by confirming the dev server is bound to localhost or otherwise restricted from untrusted networks. To test behavior safely, create a non-sensitive canary file covered by server.fs.deny and attempt to retrieve it with ?raw, ?import&raw, and ?import&url&inline; a fixed or mitigated server should not return the file contents with HTTP 200. Review deployment images and remote development templates to ensure patched dependencies are actually in use after rebuilds.

Typical attack path

1. Scan the internet or an internal network for reachable Vite development servers.
2. Fingerprint the service using Vite-specific paths, JavaScript module responses, error pages, or common dev server ports.
3. Request sensitive project files that should be denied, such as /.env, /.env.local, /config/*.crt, or key files.
4. Append bypass query strings such as ?raw, ?import&raw, or ?import&url&inline to the target file path.
5. Receive HTTP 200 responses containing sensitive file contents from a vulnerable Vite version.
6. Extract credentials, tokens, certificates, or other secrets from the disclosed files.
7. Use the stolen secrets to access cloud services, databases, source repositories, package registries, or internal APIs.

How to detect it

Review reverse-proxy, ingress, WAF, CDN, VPN, and web access logs for requests to sensitive project files with Vite query parameters, especially responses with HTTP 200 and non-trivial response sizes. Focus on paths containing .env, .env.local, .env.development, .env.production, .crt, .key, .pem, id_rsa, config, credentials, or secrets combined with query strings such as raw, import&raw, url, or inline. Vite development servers may not retain detailed access logs by default, so container stdout/stderr, process supervisor logs, reverse proxies, load balancers, and network telemetry may be the best evidence sources. Look for scanning behavior across multiple likely secret filenames from the same source IP, followed by use of credentials in cloud audit logs, source-control audit logs, package-registry logs, database authentication logs, or SaaS identity logs. If suspicious file disclosure is identified, assume exposed secrets may have been copied and rotate them rather than relying only on server-side cleanup.

• .env?raw
• .env?import&raw
• .env?import&url&inline
• .env.local?raw
• .env.local?import&raw
• .env.local?import&url&inline
• .env.development?raw
• .env.production?raw
• .crt?raw
• .crt?import&raw
• .crt?import&url&inline
• .pem?raw
• .pem?import&raw
• .pem?import&url&inline
• .key?raw
• .key?import&raw
• .key?import&url&inline
• id_rsa?raw
• id_rsa?import&raw
• id_rsa?import&url&inline
• credentials?raw
• credentials?import&raw
• secrets?raw
• ?raw
• ?import&raw
• ?import&url&inline
• /@vite/client

What your security team should do

• Prioritize patching exposed Vite development servers and remote development environments because weaponized exploitation is reported.
• Upgrade Vite to 7.3.2 or later on the 7.x branch, or 8.0.5 or later on the 8.x branch, and verify lockfiles do not retain vulnerable versions.
• Inventory Vite usage across repositories, containers, CI images, developer workspaces, and preview environments, including transitive dependency usage.
• Immediately restrict Vite dev server access to localhost, VPN, or authenticated internal networks; block direct internet exposure.
• Search HTTP access logs for requests to sensitive filenames combined with Vite query parameters and HTTP 200 responses.
• Rotate credentials, API keys, certificates, and tokens stored in project files if any vulnerable Vite dev server was exposed or suspicious access is found.
• Add WAF, reverse-proxy, or SIEM detections for sensitive file requests containing ?raw, ?import&raw, or ?import&url&inline.
• Educate development teams not to run Vite dev servers on public interfaces unless protected by strong network and authentication controls.