GHSA-V2WJ-Q39Q-566R: Vite `server.fs.deny` Bypass via Query Parameters

The Vite development server provides an integrated web server for serving application assets and source files during the development process. To protect sensitive project files, Vite implements the server.fs.deny configuration directive. This directive acts as a blocklist, utilizing an array of file path patterns to restrict network access to files such as .env, .git/, and node_modules/ directories.

The vulnerability exists in the path normalization and validation logic of the development server. When the server receives an incoming HTTP request, it evaluates the requested file path against the configured deny list patterns. However, the evaluation occurs before transformation query parameters are fully decoupled from the requested file path identifier.

By appending specific Vite-recognized query parameters to a request for a restricted file, an attacker manipulates the path string evaluated by the access control logic. This manipulation causes exact-match and suffix-based file path patterns to fail, permitting the request to bypass the intended security restrictions. The resulting impact is the unauthorized disclosure of sensitive files present on the host filesystem where the Vite process is executing.

The root cause of GHSA-V2WJ-Q39Q-566R lies in the isServerAccessDeniedForTransform function and the associated transformMiddleware within the Vite development server. These components validate incoming requests to ensure they do not attempt to read files blocked by the server.fs.deny configuration. The validation logic performs checks using the literal request id string.

In Vite's architecture, the id string often contains both the filesystem path and query parameters used to instruct the transformation pipeline (e.g., ?raw to import a file as a raw string). Because the server.fs.deny patterns are typically defined to match specific file extensions or directory paths, they are highly sensitive to the exact string representation of the requested path.

When a request targets /src/.env?raw, the access control mechanism evaluates the entire string /src/.env?raw against patterns such as **/.env*. While simple glob patterns might match this string, complex query combinations or platform-specific URL handling anomalies prevent the pattern matching logic from accurately identifying the underlying restricted file. The failure to normalize the id string prior to access validation creates an open-allow condition for restricted resources.

The vulnerable implementation evaluates the un-normalized request identifier directly against the server.fs.deny blocklist. The failure to strip transformation query parameters allows the path matching logic to return false negatives. The subsequent transformation pipeline then correctly processes the query parameters and reads the underlying file, oblivious to the fact that the file is restricted.

The patch introduced in commit a9a3df299378d9cbc5f069e3536a369f8188c8ff resolves this issue by implementing a dual-check validation mechanism. The Vite team modified packages/vite/src/node/server/middlewares/transform.ts to evaluate both the raw request identifier and a cleaned, normalized version of the URL.

// Patched implementation in packages/vite/src/node/server/middlewares/transform.ts
export function isServerAccessDeniedForTransform(
  config: ResolvedConfig,
  id: string,
): boolean {
  if (rawRE.test(id) || urlRE.test(id) || inlineRE.test(id) || svgRE.test(id)) {
    return (
      checkLoadingAccess(config, cleanUrl(id)) !== 'allowed' || // Check normalized path
      checkLoadingAccess(config, id) !== 'allowed'            // Check raw ID
    )
  }
  return false
}

The implementation now invokes cleanUrl(id), which removes query parameters and hash fragments from the path string. By evaluating both cleanUrl(id) and the raw id against the access control policies, the server ensures that any restricted file remains blocked, regardless of appended transformation parameters.

Exploitation requires network access to the target Vite development server. Developers often bind the Vite development server to all network interfaces (e.g., --host 0.0.0.0) to facilitate testing from mobile devices or external network segments. This configuration significantly increases the attack surface, allowing remote unauthenticated attackers to reach the vulnerable service.

An attacker constructs an HTTP GET request targeting a known sensitive file, such as an environment configuration file, appending a query string recognized by the Vite transformation pipeline. A common target is the .env file, which Vite actively denies by default. The attacker sends a request such as GET http://target-host:5173/src/.env?raw.

The development server receives the request and evaluates /src/.env?raw. The path matching engine fails to match this string against its deny patterns. The request is subsequently passed to the transformation logic, which processes the ?raw parameter. The server reads the .env file from disk and returns its contents directly in the HTTP response body as a raw string.

Attackers can utilize varying parameters to achieve this bypass, including ?import&raw and ?url&inline. The success of the exploit depends solely on identifying the location of the restricted file relative to the Vite server root and selecting a query parameter that the transformation engine natively parses while simultaneously evading the glob matching engine.

The direct impact of this vulnerability is the unauthorized disclosure of sensitive information residing on the development host. The scope of exposed data is constrained to the files accessible by the Vite server process. The primary risk involves the extraction of credentials, API keys, and database passwords typically stored in .env or configuration files at the project root.

Exposed secrets can facilitate immediate lateral movement or privilege escalation. If development API keys for third-party services (e.g., AWS, Stripe, Twilio) are exposed, an attacker can pivot to attack the supporting infrastructure. In shared development environments or containerized workspaces, the vulnerability allows users to read proprietary source code and intellectual property.

This vulnerability does not affect production environments serving static files generated via the vite build command. The issue is strictly confined to the vite development server process. However, the severe consequences of exposed credentials warrant immediate remediation and adherence to secure development environment configurations.

The vulnerability is completely resolved in Vite versions 7.3.2 and 8.0.5. Organizations utilizing vulnerable versions of Vite must upgrade their dependencies immediately. Project maintainers can apply the fix by running package manager update commands, such as npm update vite or yarn upgrade vite, and ensuring the resulting version meets the patched baseline.

If immediate upgrading is not feasible, developers must restrict network access to the Vite development server. By default, Vite binds to localhost, which limits exposure to local users. Developers must avoid using the --host flag or configuring server.host to 0.0.0.0 unless operating within an isolated, trusted network environment. Network-level controls, such as local firewalls or VPNs, should be employed to protect the development instance.

Organizations should also implement defense-in-depth measures regarding secret management. Development secrets should be distinct from production secrets, limiting the blast radius of a credential disclosure event. Utilizing secret management vaults instead of plain text .env files further mitigates the risk of exposure during development operations.