GHSA-4W7W-66W2-5VF9: Path Traversal in Vite transformMiddleware Source Map Handling

The Vite development server provides an environment for modern web application development, offering features like Hot Module Replacement (HMR) and optimized dependency pre-bundling. During the pre-bundling phase, Vite processes and caches dependencies within the node_modules/.vite/deps directory to improve server start times and page load performance. The server uses various middleware components to handle requests for these optimized assets, including source map files that assist in debugging.

A vulnerability identified as GHSA-4W7W-66W2-5VF9 exists in the source map handling mechanism of Vite's transformation middleware. The specific flaw is a path traversal vulnerability (CWE-22) that occurs when the server processes requests for files ending with the .map extension. The middleware calculates the physical file path on the host filesystem based on the incoming request URL but fails to enforce strict directory boundaries.

This insufficient validation allows a remote or unprivileged local attacker to construct crafted HTTP requests containing directory traversal sequences. By appending ../ sequences to the optimized dependencies base path, the attacker can navigate outside the intended .vite/deps directory. The vulnerability exposes the host filesystem to unauthorized file read operations, subject to specific parsing constraints enforced by the server.

The root cause of this path traversal vulnerability resides in transformMiddleware, implemented within packages/vite/src/node/server/middlewares/transform.ts. This middleware is responsible for transforming requested modules and serving associated source map files. When the middleware detects a request for a file with a .map extension, it enters a dedicated code block designed to locate and return the source map content.

To determine the target file location, the middleware computes the sourcemapPath variable. Depending on the request URL structure, it either uses fsPathFromId(url) for paths starting with a predefined filesystem prefix or constructs the path by resolving the URL suffix against the server root using path.resolve(). The resulting absolute path represents the intended location of the source map file on the host operating system.

The critical failure occurs immediately after this path resolution step. The implementation assumes that the request URL, and subsequently the resolved sourcemapPath, will inherently point to a location within the authorized optimized dependencies directory. It lacks an explicit boundary check or jail validation mechanism to verify that the final physical path does not escape the node_modules/.vite/deps hierarchy. Consequently, the middleware blindly passes the resolved traversal path to the filesystem read operation.

Prior to the patch, the transformMiddleware handled the path resolution process without verifying the structural integrity of the final directory path. The vulnerable implementation directly utilized the resolved sourcemapPath in an asynchronous filesystem read operation. If the file existed and the read succeeded, the server proceeded to parse the file contents as JSON.

const sourcemapPath = url.startsWith(FS_PREFIX)
  ? fsPathFromId(url)
  : normalizePath(path.resolve(server.config.root, url.slice(1)))
 
try {
  const map = JSON.parse(
    await fsp.readFile(sourcemapPath, 'utf-8'),
  )
  // Execution continues to serve the map content
}

The patch introduced in commit 79f002f2286c03c88c7b74c511c7f9fc6dc46694 addresses the vulnerability by adding a mandatory validation step before the filesystem read operation. The developers leveraged the existing depsOptimizer utility to ensure the resolved path strictly corresponds to a known optimized dependency file. If the isOptimizedDepFile check fails, the middleware immediately yields control to the next handler, preventing unauthorized access.

const sourcemapPath = url.startsWith(FS_PREFIX)
  ? fsPathFromId(url)
  : normalizePath(path.resolve(server.config.root, url.slice(1)))
 
// url may contain relative path that may resolve outside of the optimized deps directory
if (!depsOptimizer.isOptimizedDepFile(sourcemapPath)) {
  return next()
}
 
try {
  const map = JSON.parse(
    await fsp.readFile(sourcemapPath, 'utf-8'),
  )

Exploiting this path traversal vulnerability requires the attacker to send a specifically formatted HTTP GET request to the Vite development server. The request must target the @fs endpoint or the standard optimized dependencies path, injecting directory traversal characters (../) to construct a relative path to the target file. The Vite routing mechanism passes this URL to the transformMiddleware for processing.

The exploitation is constrained by two critical requirements enforced by the middleware logic. First, the requested file path must terminate with the .map extension, as the vulnerable code path is only triggered for source map requests. Second, the target file must contain strictly valid JSON data. The middleware executes JSON.parse() on the file contents immediately after reading; if the parsing fails, an exception is thrown, and the file contents are not returned to the attacker.

A practical proof-of-concept attack involves targeting known configuration files or existing source maps on the host operating system that satisfy these constraints. For example, a request to http://localhost:5173/@fs/C:/path/to/project/node_modules/.vite/deps/../../../../Windows/System32/some_config.json.map will successfully return the contents of some_config.json.map assuming the file exists and contains valid JSON. This demonstrates the capability to traverse outside the project root and access arbitrary locations on the storage volume.

The security impact of GHSA-4W7W-66W2-5VF9 is evaluated as moderate due to the strict preconditions required for successful data exfiltration. While the vulnerability grants arbitrary file read capabilities across the host filesystem, the requirement that the target file must end in .map and contain valid JSON significantly limits the scope of accessible data. The attacker cannot read standard configuration files like /etc/passwd or .env, as these lack the .map extension and do not conform to JSON formatting.

Despite these constraints, the vulnerability poses a risk to intellectual property and specific environment configurations. Attackers can target legitimate source map files residing in unrelated project directories on the same host. These source maps often contain embedded, unminified source code in the sourcesContent array, potentially exposing proprietary algorithms, internal API endpoints, or hardcoded credentials left in the source code of other applications.

The overall risk is heavily dependent on the network exposure of the Vite development server. By default, Vite binds to the local loopback interface (localhost), restricting exploitation to local attackers or scenarios involving cross-site request forgery (CSRF) in complex environments. However, if the developer explicitly configures the server to listen on all interfaces (using the --host flag), the attack surface expands to the local area network or the public internet, substantially increasing the likelihood of remote exploitation.

The primary remediation for GHSA-4W7W-66W2-5VF9 is to update the Vite package to a patched release. The Vite maintenance team has issued patches across multiple major version lines. Developers must upgrade their project dependencies to Vite version 6.4.2, 7.3.2, or 8.0.5, depending on the major version currently in use. This update introduces the necessary path validation logic via the depsOptimizer.isOptimizedDepFile() function, neutralizing the traversal vector.

In environments where immediate patching is not feasible, security engineers should implement network-level mitigations to restrict access to the development server. Ensure that the Vite process is not launched with the --host 0.0.0.0 argument unless strictly required for specific testing scenarios. Restricting the service binding to 127.0.0.1 prevents remote attackers from communicating with the vulnerable middleware, effectively mitigating external exploitation attempts.

Additionally, development teams should review their filesystem architecture to ensure sensitive JSON configurations do not utilize the .map extension. While this is an uncommon pattern, eliminating potential target files reduces the residual risk in complex development environments. Implementing endpoint detection and response (EDR) rules or web application firewall (WAF) policies to flag consecutive ../ sequences in requests targeting port 5173 can provide an interim defensive layer.