CVE-2026-76844 in webpack-dev-middleware
Summary
by MITRE • 08/24/2026
webpack-dev-middleware resolves a request to a local file in getFilenameFromUrl by testing the request pathname against a traversal guard and then slicing it at a fixed character offset. The guard, UP_PATH_REGEXP applied to path.normalize(`./${pathname}`), only matches ".." that stands as a whole path segment, while the containment test is the string comparison pathname.startsWith(publicPathPathname) and the file path is built as path.join(outputPath, pathname.slice(publicPathPathname.length)). When the configured publicPath has no trailing slash, a request such as GET /assets../.env against publicPath /assets yields the pathname /assets../.env, whose only dot-dot sits inside the segment "assets.." and so passes the guard, but the offset slice cuts within that segment and hands "../.env" to path.join, resolving one directory above outputPath. Reading a file from that path requires the middleware to be backed by the physical filesystem, which happens when writeToDisk is true or a custom outputFileSystem is supplied, since the default memfs volume holds only build output. Traversal depth is limited to a single directory because a separately delimited dot-dot segment is collapsed during URL parsing before the guard runs. The default publicPath value of "auto" resolves to "/" and is not affected. This is an incomplete fix for CVE-2024-29180: the guard and offset slice were introduced by that fix and are present in every release from 5.3.4, 6.1.2 and 7.1.0 onward.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified as CVE-2024-29180 represents a critical path traversal flaw within the webpack-dev-middleware component, specifically affecting how requests are resolved to local files via the getFilenameFromUrl function. This security issue stems from an incomplete remediation strategy implemented in previous versions of the middleware. The core technical failure lies in the logic used to validate and sanitize incoming request paths before they are joined with the output directory path. Specifically, the middleware employs a regular expression guard known as UP_PATH_REGEXP to detect directory traversal attempts by looking for double-dot sequences that constitute whole path segments. However, this validation mechanism is bypassed when an attacker constructs a pathname where the dot-dot sequence is embedded within a single segment rather than standing alone as a distinct delimiter-separated component.
The operational mechanics of the exploit involve manipulating the publicPath configuration and the request URL structure to evade detection. When the configured publicPath does not end with a trailing slash, such as /assets, an attacker can craft a malicious request like GET /assets../.env. In this scenario, the resulting pathname is /assets../.env. The validation logic first applies path.normalize to ./pathname and then checks if it contains ".." as a whole segment using UP_PATH_REGEXP. Because "assets.." is treated as a single filename segment by standard URL parsing rules before the guard runs, the double dots do not appear as separate segments, allowing them to pass the security check undetected. Subsequently, the middleware slices the pathname at an offset determined by the length of publicPathPathname. In this example, slicing /assets../.env after "assets" results in "../.env", which is then passed to path.join along with the outputPath directory.
This sequence of operations leads directly to arbitrary file read capabilities on the underlying filesystem where the middleware is deployed. The path.join function interprets the resulting "../.env" as a relative reference moving one level up from the output directory, thereby accessing sensitive files such as environment configuration files or source code outside the intended web root. This exploitation vector is only effective when the middleware is configured to write to disk, indicated by setting writeToDisk to true, or when a custom outputFileSystem implementation that interacts with the physical file system is provided. The default memory-based filesystem (memfs) does not expose these vulnerabilities because it strictly holds build outputs and lacks direct access to the host operating system's directory structure.
The severity of this vulnerability is compounded by its presence across multiple major versions of webpack-dev-middleware, including releases from 5.3.4 onwards for version 5.x, 6.1.2 onwards for version 6.x, and 7.1.0 onwards for version 7.x. This indicates that the flawed fix was propagated through subsequent updates without adequate re-evaluation of edge cases involving segment boundary conditions. The default publicPath value of "auto" resolves to "/" which inherently prevents this specific traversal pattern because the slicing logic does not produce a relative path with upward movement, leaving those configurations safe from this particular attack vector.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it allows an actor to access files and directories that are located outside the restricted directory intended by the application's security policy. Furthermore, in terms of tactical behavior, this exploitation technique corresponds to ATT&CK T1083: File and Directory Discovery, where adversaries probe for sensitive information stored on local systems. The lack of robust input validation regarding segment boundaries highlights a common oversight in path manipulation logic that relies solely on simple string matching rather than comprehensive canonicalization checks.
To mitigate this vulnerability, organizations must ensure they are running patched versions of webpack-dev-middleware that address the incomplete fix from CVE-2024-29180. Developers should audit their configurations to avoid using publicPath values without trailing slashes when combined with dynamic request handling logic. Additionally, it is crucial to restrict the use of writeToDisk or custom file system implementations in development environments unless absolutely necessary, as these features expand the attack surface by exposing the physical filesystem to web server inputs. Implementing strict allowlists for permitted paths and utilizing robust path canonicalization libraries that correctly handle segment boundaries can further harden applications against similar traversal attacks. Regular security assessments focusing on input validation patterns are recommended to identify and remediate such logic flaws before they can be exploited in production environments.