CVE-2024-45811

What it actually does

Affected Vite development server versions incorrectly enforce the @fs file-serving allow list when a requested file URL includes the query parameters `?import&raw`. The intended protection blocks browser access to files outside the configured Vite serving allow list, but the bypass can cause Vite to read an arbitrary existing file from the host filesystem and return its contents in the HTTP response. The impact is confidentiality-only: it can expose source code, environment files, credentials, local configuration, SSH keys, package tokens, cloud secrets, or other files readable by the Vite process. It does not directly provide code execution, file modification, or denial of service.

Why it matters to the business

If an affected Vite dev server is reachable by an attacker, sensitive local files may be exposed from developer workstations, CI runners, preview environments, or internal build systems. The most likely business consequence is credential and secret leakage, which can lead to follow-on compromise of source repositories, package registries, cloud services, CI/CD systems, or internal applications. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing and no known mature public exploitation signal in the provided data, but the risk is higher where Vite dev servers are exposed beyond localhost or are used in shared development and preview environments.

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 craft requests using the Vite filesystem access route pattern, such as an `@fs` URL, and append `?import&raw` to force Vite to treat the target as a raw import. In vulnerable versions, this query combination bypasses the file-serving allow-list check and returns the contents of the requested file if the file exists and the Vite process has read permission. The attacker iterates through likely high-value paths such as project `.env` files, package manager configuration, SSH material, cloud credentials, or source files. Any recovered secrets can then be used for secondary access against development tooling, repositories, registries, cloud accounts, or deployment pipelines.

How to fix it

Upgrade Vite to a patched release. Fixed versions are 5.4.6, 5.3.6, 5.2.14, 4.5.5, and 3.2.11; source builds should include fix commit `f9691767ad763720065cc7c5c7f369f97b4e7ea8` or later. There are no known safe workarounds for the vulnerable parsing behavior itself. As defense in depth, ensure Vite development servers are not exposed to untrusted networks, bind dev servers to localhost where possible, restrict access using firewall/VPN controls, avoid running Vite with broad filesystem permissions, and keep secrets out of files readable by development server processes. Rotate any credentials that may have been exposed if exploitation is suspected.

How to confirm the fix worked

Confirm the installed Vite version is one of the patched releases or newer: 5.4.6+, 5.3.6+, 5.2.14+, 4.5.5+, or 3.2.11+, depending on the maintained branch in use. For source-based deployments, verify the code contains commit `f9691767ad763720065cc7c5c7f369f97b4e7ea8` or an equivalent patch. Review `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, and dependency manifests to ensure transitive or workspace uses of Vite are not pinned to affected versions. Validate exposure by checking that Vite dev servers are not reachable from untrusted networks and are bound only to intended interfaces. In a controlled test environment, a request attempting to access a file outside the Vite allow list using `@fs` plus `?import&raw` should be denied rather than returning file contents.

Typical attack path

1. Discover a Vite development server exposed on localhost via browser pivoting, an internal network, VPN, container network, preview environment, or an accidentally internet-exposed dev port.
2. Confirm Vite behavior by requesting known Vite endpoints or observing Vite-specific response headers, JavaScript module transforms, or error pages.
3. Send crafted `@fs` file requests with the `?import&raw` query string appended.
4. Target likely sensitive files readable by the Vite process, such as project environment files, user configuration files, package manager credentials, source files, or cloud credential files.
5. Review successful HTTP responses for secrets, credentials, tokens, private keys, or internal application details.
6. Use exposed secrets for follow-on access to source control, package registries, CI/CD platforms, cloud services, or other connected systems.

How to detect it

Review web server, reverse proxy, Vite dev server, container stdout/stderr, EDR network telemetry, and developer workstation logs for requests containing both an `@fs` path and the query parameters `import` and `raw`. Prioritize requests for sensitive paths such as `.env`, SSH directories, cloud credential files, package manager config files, source files, and operating system account files. Look for successful HTTP 200 responses with unusually large response bodies or response bodies containing secrets after such requests. Also review network flow logs for unexpected access to Vite development ports, commonly 5173, 4173, 3000, 3001, 8080, or other configured dev ports, especially from non-developer subnets or external IP addresses. If exploitation is suspected, preserve access logs and affected host artifacts, determine the Vite process user and readable file scope, and rotate credentials from any file that may have been requested. There are no named threat actors or ransomware campaigns associated with the provided data, and the vulnerability is not listed in CISA KEV in the provided input.

• @fs
• ?import&raw
• @fs/
• /@fs/
• import&raw
• raw&import
• %40fs
• %3Fimport%26raw
• %26raw
• /.env?import&raw
• /.env.local?import&raw
• /.env.development?import&raw
• /.env.production?import&raw
• /etc/passwd?import&raw
• /etc/hosts?import&raw
• /.ssh/id_rsa?import&raw
• /.ssh/config?import&raw
• /.aws/credentials?import&raw
• /.npmrc?import&raw
• /.yarnrc?import&raw
• /package.json?import&raw
• /pnpm-lock.yaml?import&raw
• /yarn.lock?import&raw
• /package-lock.json?import&raw
• vite --host 0.0.0.0
• VITE v

What your security team should do

• Inventory Vite usage across development workstations, CI jobs, containers, preview environments, and internal tooling; prioritize any instance reachable beyond localhost.
• Upgrade all affected Vite branches to the applicable patched version: 5.4.6, 5.3.6, 5.2.14, 4.5.5, 3.2.11, or a source revision containing commit `f9691767ad763720065cc7c5c7f369f97b4e7ea8`.
• Block untrusted network access to Vite development ports and require localhost binding or controlled VPN/firewall access for dev servers.
• Search HTTP access logs, reverse proxy logs, container logs, and endpoint telemetry for `@fs` requests containing `import` and `raw` query parameters.
• If suspicious requests are found, identify which files may have been returned and rotate any exposed credentials, tokens, SSH keys, cloud keys, or package registry tokens.
• Add dependency checks to CI to prevent reintroduction of vulnerable Vite versions in package manifests and lockfiles.
• Educate developers not to expose Vite dev servers directly to the internet or shared untrusted networks.