The webpack-dev-middleware package is safe once you upgrade to version 7.1.0, 6.1.2, or 5.3.4 depending on your major line, which closes CVE-2024-29180 — a path traversal flaw that let a crafted request URL read arbitrary files from the machine running the dev server. If you run webpack's dev server, you almost certainly depend on webpack dev middleware, so this is worth a quick lockfile check even though it only affects development.
webpack-dev-middleware is the component that serves your compiled bundle from memory during development. It sits between your dev server and webpack's output, intercepting requests and returning the freshly built assets. Because it maps request URLs to files, URL handling is exactly where a path traversal bug can appear.
What CVE-2024-29180 does
CVE-2024-29180 is a path traversal vulnerability in webpack-dev-middleware. The middleware did not properly validate the supplied URL before returning a local file, so an attacker could craft a request that escaped the intended output directory and reached any file the dev-server process could read.
The attack path is the classic traversal pattern: a request URL containing directory-traversal sequences (like ..) or a null byte that the middleware resolved to a file outside the served directory. Because a developer's machine often holds SSH keys, cloud credentials, environment files, and source for other projects, the potential to read arbitrary local files is more serious than "it's only dev" makes it sound.
There is a realistic delivery vector, too. A developer's dev server usually listens on a local port, but a malicious web page the developer visits can issue cross-origin requests to localhost, so this is not purely a "someone on my network" problem.
Which versions are affected and fixed
The maintainers patched the issue across the supported major lines. The fixed versions are:
- v7.x:
7.1.0or later - v6.x:
6.1.2or later - v5.x:
5.3.4or later
Versions below the relevant threshold — up to 5.3.3, up to 6.1.1, and the early 7.0.x releases before 7.1.0 — are vulnerable. In the patched releases the URL is unescaped and normalized before any further processing, and the resolver rejects URLs containing null bytes or traversal patterns.
Checking and fixing your project
webpack-dev-middleware is almost always transitive — it comes in through webpack-dev-server, framework CLIs, and build tooling — so start by finding what you actually resolved:
npm ls webpack-dev-middleware
If a copy sits below the fixed version, the cleanest fix is to update the parent that pulls it in (usually webpack-dev-server). When a parent pins an old range and you cannot upgrade it immediately, an overrides block forces the patched version:
{
"overrides": {
"webpack-dev-middleware": "^7.1.0"
}
}
Pick the override version that matches the major line the rest of your toolchain expects — forcing v7 under a parent that assumed v5 can break the dev server, so test the dev build after applying it.
Why "dev-only" is not "ignore it"
It is tempting to deprioritize anything that only runs in development, but development machines are high-value targets precisely because they hold the keys to production. A path traversal on a developer laptop can hand over cloud credentials, signing keys, or a .env full of secrets. Treat build-tooling vulnerabilities that can read the local filesystem with the same seriousness as a production dependency, especially when the exploit can be triggered by a web page rather than requiring local network access.
A couple of habits reduce this exposure generally:
- Bind the dev server to
127.0.0.1, not0.0.0.0, so it is not reachable from the network. This does not stop the malicious-webpage vector, but it removes the network one. - Keep credentials out of the project directory where practical, so a filesystem read against the dev server has less to grab.
Keeping build tooling patched
Build and dev-time dependencies drift out of date faster than runtime ones because they feel invisible — nothing in production points at them. The fix is to include devDependencies in your automated scanning, not just production dependencies, so a new advisory against something like webpack-dev-middleware opens a pull request instead of lingering. Our overview of software composition analysis explains how transitive advisories propagate through a lockfile, which is what determines whether you are actually exposed to CVE-2024-29180 through a dependency you never installed directly.
FAQ
What versions fix CVE-2024-29180 in webpack-dev-middleware?
Upgrade to 7.1.0 on the v7 line, 6.1.2 on v6, or 5.3.4 on v5. Any of these normalizes and validates the request URL before serving a file.
Does CVE-2024-29180 affect production?
Not directly — webpack-dev-middleware runs during development, not in production builds. But it can expose a developer's local files, including credentials, so it is not something to ignore just because it is dev-only.
I never installed webpack-dev-middleware. Why is it in my project?
It is pulled in transitively, usually by webpack-dev-server or a framework's build CLI. Run npm ls webpack-dev-middleware to see which parent brought it in and at what version.
How can an attacker reach my local dev server?
Beyond someone on your network, a malicious web page you visit can send cross-origin requests to your dev server on localhost. That is why binding to 127.0.0.1 helps but does not fully close the risk on a vulnerable version — patching does.