CVE-2026-118662: Access Control Bypass via Uncanonicalized Query Parameters in Vite Development Server

Vite (vitejs/vite) is a widely deployed build tool and development server for modern JavaScript and TypeScript web applications. During local development, Vite runs an HTTP server that intercepts browser module requests, applies on-demand code transformations, and serves source files directly from the host filesystem. Because serving arbitrary files from a developer workstation or build container presents security risks, Vite implements a two-tiered filesystem access control mechanism governed by the server.fs.allow and server.fs.deny configuration properties.

By default, server.fs.allow permits the development server to serve files located within the project workspace root, while server.fs.deny explicitly restricts access to sensitive files that frequently coexist within the workspace. The default denylist blocks access to environment files (**/.env, **/.env.*), private certificates (*.{crt,pem}), and version control metadata (**/.git/**). Even if a file resides inside an allowed directory, any match against server.fs.deny is intended to terminate the request with an HTTP 403 Forbidden response.

CVE-2026-118662 is a validation-before-canonicalization vulnerability (CWE-180) resulting in improper access control (CWE-284) within Vite's transformation middleware (packages/vite/src/node/server/middlewares/transform.ts). In Vite version 6.4.4, the helper function responsible for verifying filesystem access permissions during module transformations evaluates the target module identifier before stripping URL query parameters. When an HTTP request includes Vite-specific loader queries—such as ?raw, ?url, or ?inline—the un-sanitized identifier is passed directly to the glob-matching engine.

Because glob rules like **/.env expect a clean filename boundary at the end of the string, the presence of a trailing query string causes the denylist pattern match to fail. The access check erroneously concludes that the file is not restricted, and the subsequent loader logic strips the query parameter to read the actual file from disk. If the Vite development server is bound to a network interface via --host or equivalent configuration, an unauthenticated attacker on the network can exploit this discrepancy to read sensitive configuration files and credentials.

To understand the root cause of CVE-2026-118662, it is necessary to examine how Vite processes incoming HTTP requests for static and transformed assets. When a browser or HTTP client requests a module from the Vite development server, the request passes through a series of Connect-based middleware handlers. One of the primary handlers is the transform middleware, which resolves module identifiers, loads file contents from disk, and runs plugin transform pipelines.

Vite supports specialized resource import queries that instruct the build tool on how to load a specific asset. These queries are matched in packages/vite/src/node/server/middlewares/transform.ts using regular expressions: rawRE matches ?raw (loads the file content as a raw string export), urlRE matches ?url (returns the asset's resolved URL), inlineRE matches ?inline (inlines the asset as base64 or data URI), and svgRE matches .svg files that may undergo transformation. When any of these patterns match the requested module identifier id, the middleware invokes isServerAccessDeniedForTransform(id) to verify whether the file is permitted to be served.

The core defect in Vite 6.4.4 lies in the ordering of canonicalization and validation inside isServerAccessDeniedForTransform. The function receives the raw module identifier id, which retains its query string components (for example, /app/.env?raw or /app/src/deny/secret.txt?import&raw). In the vulnerable implementation, isServerAccessDeniedForTransform passes id directly to checkLoadingAccess(config, id) without calling Vite's internal cleanUrl() utility to strip query parameters and hash fragments.

Inside checkLoadingAccess, Vite checks whether the requested path matches any picomatch glob pattern defined in config.server.fs.deny, and subsequently checks whether the path resides within the directory hierarchy allowed by config.server.fs.allow. When evaluating a denylist pattern such as **/.env or **/deny/** against a path ending with ?raw, the glob matcher treats ?raw as part of the filename itself. For exact filename globs (like **/.env) or extension-based globs (like *.{crt,pem}), the trailing query characters prevent a match. Meanwhile, the directory allowlist check evaluates whether the file resides inside the workspace root directory; because /app/.env?raw is still lexically child to /app/, the server.fs.allow check succeeds. Consequently, checkLoadingAccess returns 'allowed', and the transform pipeline proceeds to strip the query parameters during the actual disk read phase, serving the restricted file contents to the requester.

The vulnerability and its corresponding fix are localized within packages/vite/src/node/server/middlewares/transform.ts. In Vite 6.4.4, the isServerAccessDeniedForTransform function was implemented to gate access to assets requested with transform query suffixes.

// Vulnerable implementation in Vite 6.4.4
// File: 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)) {
    // FLAW: 'id' contains the query string (e.g., '/path/to/.env?raw').
    // Denylist patterns in config.server.fs.deny fail to match the uncleaned path.
    return checkLoadingAccess(config, id) !== 'allowed'
  }
  return false
}

Notice the paradoxical condition in the vulnerable code: the if statement specifically enters the validation block because id matched a query parameter regular expression (rawRE, urlRE, or inlineRE), or svgRE. Thus, for three out of the four trigger conditions, id is guaranteed to contain a query string at the exact moment checkLoadingAccess(config, id) is called.

In commit 91e40d7bf9777057bbd31c3eb036a54c9465697e (released in Vite 6.4.5), the maintainers modified isServerAccessDeniedForTransform to canonicalize the identifier via cleanUrl(id) prior to checking loading access, while retaining the check against the raw id as well:

--- a/packages/vite/src/node/server/middlewares/transform.ts
+++ b/packages/vite/src/node/server/middlewares/transform.ts
@@ -58,7 +58,10 @@ export function isServerAccessDeniedForTransform(
   id: string,
 ): boolean {
   if (rawRE.test(id) || urlRE.test(id) || inlineRE.test(id) || svgRE.test(id)) {
-    return checkLoadingAccess(config, id) !== 'allowed'
+    return (
+      checkLoadingAccess(config, cleanUrl(id)) !== 'allowed' ||
+      checkLoadingAccess(config, id) !== 'allowed'
+    )
   }
   return false
 }

The cleanUrl helper function (defined in Vite's shared utilities using const postfixRE = /[?#].*$/ to replace everything from the first ? or # onward with an empty string) strips all query parameters and URL fragments. By evaluating checkLoadingAccess(config, cleanUrl(id)) !== 'allowed', an input such as /project/.env?import&raw is normalized to /project/.env before being tested against server.fs.deny.

Retaining both cleanUrl(id) and the uncleaned id check in a logical OR (||) statement provides completeness against variant bypasses. If a custom server.fs.deny rule targets specific query patterns or if a crafted filename literally contains a question mark on filesystems that permit it, evaluating both the stripped and unstripped representations ensures that if either representation violates the access policy, access is denied. Additionally, the upstream patch expanded the regression test suite in playground/fs-serve/__tests__/deny/fs-serve-deny.spec.ts and playground/fs-serve/__tests__/commonTests.ts to verify that single and compound query suffixes (such as ?.svg?import and ?.svg?.wasm?init) consistently return HTTP 403 Forbidden.

Exploiting CVE-2026-118662 requires no authentication or specialized tooling; it can be executed using standard HTTP clients such as curl or a web browser. However, two architectural prerequisites must be satisfied for an application to be vulnerable to remote exploitation.

First, the Vite development server must be reachable by the attacker over the network. By default, Vite binds only to the local loopback interface (localhost / 127.0.0.1). For a remote attacker to reach the service, the developer or container orchestration environment must have configured Vite to listen on all network interfaces by passing the --host CLI flag (vite --host 0.0.0.0) or setting server.host: true in vite.config.js. Alternatively, local exploitation or cross-origin attacks could occur if an attacker has local network adjacency or leverages port-forwarding mechanisms.

Second, the target file must reside within a directory permitted by server.fs.allow while simultaneously being restricted by server.fs.deny. Because Vite's default configuration allows serving files from the entire project root directory and uses server.fs.deny to block sensitive files within that root (specifically .env, .env.*, *.crt, *.pem, and .git/**), any standard Vite project containing a .env file in its root or src/ directory satisfies this second prerequisite out of the box.

When a direct request is made to a restricted file without query manipulation, Vite blocks the request:

GET /.env HTTP/1.1
Host: target-dev-server:5173
 
HTTP/1.1 403 Forbidden

To bypass server.fs.deny, the attacker appends one of the transform loader queries recognized by isServerAccessDeniedForTransform. The upstream regression tests in commit 91e40d7bf9777057bbd31c3eb036a54c9465697e demonstrate several effective query payloads:

# Bypassing server.fs.deny using the ?raw loader query
curl -i "http://target-dev-server:5173/.env?raw"
 
# Bypassing using compound import and raw queries
curl -i "http://target-dev-server:5173/src/.env?import&raw"
 
# Bypassing using inline or url queries
curl -i "http://target-dev-server:5173/.env?inline"
curl -i "http://target-dev-server:5173/.env?url"
 
# Bypassing using compound extension/loader queries
curl -i "http://target-dev-server:5173/src/deny/.deny?.svg?import"
curl -i "http://target-dev-server:5173/src/deny/.deny?.svg?.wasm?init"

When the vulnerable server (Vite 6.4.4) processes GET /.env?raw, the transform middleware intercepts the request, passes /.env?raw to checkLoadingAccess, and receives an 'allowed' verdict. The raw loader plugin then strips ?raw, reads the .env file from disk, wraps its contents in a standard JavaScript ES module export default "..." statement, and returns an HTTP 200 OK response containing the full cleartext environment variables.

The security impact of CVE-2026-118662 is primarily confined to unauthorized information disclosure, though the downstream consequences depend heavily on the contents of the exposed files. The vulnerability is scored at 6.9 (Medium) under CVSS v4.0 with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N.

In the CVSS v4.0 assessment, Attack Requirements (AT:P) is marked as Present because the Vite development server is not exposed to external networks in its default configuration (localhost binding) and requires specific filesystem overlap between server.fs.allow and server.fs.deny. Vulnerable System Confidentiality impact is rated Low (VC:L) because the attacker cannot traverse outside the directories explicitly permitted by server.fs.allow (for example, arbitrary system files like /etc/passwd cannot be read unless / is in server.fs.allow).

However, Subsequent System Confidentiality (SC:H) is rated High. In modern web development workflows, .env, .env.local, and .env.development files located in the project root routinely store sensitive credentials for external infrastructure. These often include cloud provider API keys (AWS, GCP, Azure), database connection strings, OAuth client secrets, payment gateway tokens, and TLS private keys (*.pem, *.crt).

Additionally, because **/.git/** is guarded by server.fs.deny inside the allowed project root, an attacker can use the ?raw or ?inline bypass to download internal Git repository objects, configuration files (.git/config), and commit histories. Exfiltrating these credentials or source code artifacts frequently enables lateral movement into cloud environments, backend databases, or source code management platforms. At the time of writing, the EPSS score for CVE-2026-118662 is 0.00295 (22.10th percentile), and there is no evidence of active exploitation in the wild or inclusion in CISA's Known Exploited Vulnerabilities (KEV) catalog.

The primary remediation for CVE-2026-118662 is to upgrade the vite package to version 6.4.5 or later. Version 6.4.5 incorporates commit 91e40d7bf9777057bbd31c3eb036a54c9465697e, which enforces path canonicalization via cleanUrl() before evaluating server.fs access rules in the transform middleware.

Development teams can apply the update using their respective Node.js package manager:

# Using npm
npm install vite@^6.4.5 --save-dev
 
# Using pnpm
pnpm update vite
 
# Using yarn
yarn upgrade vite

> [!NOTE] > This specific regression only affects Vite 6.4.4 (>= 6.4.4, < 6.4.5). Organizations should verify their lockfiles (package-lock.json, pnpm-lock.yaml, or yarn.lock) to confirm whether 6.4.4 is pinned in active development branches or CI/CD preview environments.

In scenarios where an immediate package upgrade cannot be performed, or as a general defense-in-depth practice, organizations should enforce strict network and configuration controls around Vite development servers:

1. Restrict Network Binding: Ensure the Vite development server is bound strictly to 127.0.0.1 (localhost). Remove --host or --host 0.0.0.0 flags from package.json scripts and set server.host: 'localhost' in vite.config.js. Never use vite dev or vite serve to serve traffic in production or untrusted staging environments.
2. Isolate Secrets from server.fs.allow: Where possible, store sensitive .env files or private keys outside the directories listed in server.fs.allow, or restrict server.fs.allow strictly to the client source subdirectory (e.g., ./src and ./public) rather than the entire workspace root.
3. Enforce Network-Layer Filtering: If a development server must be shared across a network (such as in a cloud development environment or containerized preview environment), place it behind an authenticating reverse proxy or Web Application Firewall (WAF) that blocks requests targeting hidden dotfiles (.env, .git) regardless of query parameters.