webpack-dev-middleware resolves a request to a local file in getFilenameFromUrl by testing the request…

webpack-dev-middleware is an Express-style development helper that serves webpack-compiled assets from memory during local development. The getFilenameFromUrl function fails to unescape and normalize URL-encoded sequences (%2e, %2f) before resolving file paths, allowing an attacker to break out of the public directory and read arbitrary files from the developer's filesystem. Affected versions: <5.3.4, >=6.0.0 <6.1.2, >=7.0.0 <7.1.0. The PoC is trivial: curl localhost:8080/public/..%2f..%2f..%2f..%2f../etc/passwd. The writeToDisk: true configuration option must be set for the traversal to return useful content in many setups.

The vendor rates this HIGH 7.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N). That score is technically defensible in a vacuum: unauthenticated, low-complexity, high-confidentiality impact. But it completely ignores the deployment context. webpack-dev-middleware is explicitly a development-only tool — the npm README, the webpack docs, and every best-practice guide say *do not run this in production*. The realistic attack surface is a developer's laptop listening on localhost:8080, reachable only via a cross-origin request from a malicious page the developer visits. In an enterprise fleet of 10,000 hosts, the number running an exposed webpack dev server at any given moment is vanishingly small. The vendor HIGH overstates the operational risk for defenders managing production infrastructure.

Why this verdict

• Dev-only tool, not production software. webpack-dev-middleware runs transiently on developer laptops during active coding sessions. In a 10,000-host fleet, the number of hosts running a vulnerable dev server at any given time is likely single digits. This alone compresses the exposure window by 2+ orders of magnitude versus the CVSS assumption of a persistent network service.
• User interaction required (UI:R). The default bind is localhost, meaning the attacker cannot reach the port directly. Exploitation requires the developer to visit a malicious page while the dev server is running — a narrow timing window combined with social engineering.
• Read-only impact, no code execution. The chain ends at file read. There is no RCE, no write primitive, no persistence. Stolen credentials (SSH keys, cloud tokens) could enable follow-on attacks, but that requires chaining and depends on whether the developer stores unprotected secrets on disk.
• writeToDisk prerequisite. Many configurations do not set writeToDisk: true, limiting traversal to the in-memory webpack output filesystem rather than arbitrary disk files.
• Role multiplier: This component occupies a low-value role (developer workstation tooling). It is NOT a domain controller, hypervisor, CI/CD server, identity provider, backup system, or network edge appliance. Even if a developer workstation is compromised via credential theft, the blast radius is host-level (one developer's files), not fleet-scale. In CI/CD pipelines, webpack-dev-middleware is not used — webpack build runs instead. The high-value-role floor does not apply.

Why not higher?

The vendor's HIGH (7.4) assumes a persistently reachable network service with high-confidentiality impact. In reality, the tool is development-only, transient, defaults to localhost, and requires victim interaction. No in-the-wild exploitation, no KEV listing, and EPSS in the bottom third all confirm this is not attracting attacker attention. The read-only impact with no RCE caps the blast radius.

Why not lower?

A public PoC exists and the exploit is trivial (single curl command). Developers *do* sometimes bind to 0.0.0.0 for mobile testing or Docker workflows, and webpack-dev-server *does* set permissive CORS headers by default. Stolen SSH keys or cloud credentials from a developer workstation can enable meaningful follow-on attacks. LOW would understate the residual risk for organizations with large JavaScript development teams.

1. Pin webpack-dev-middleware to patched versions in package.json — Set webpack-dev-middleware to >=5.3.4 (v5), >=6.1.2 (v6), or >=7.1.0 (v7) in all project package.json files. Run npm audit fix or yarn upgrade across repositories. This is the definitive fix and should be completed within the 365-day noisgate remediation SLA for MEDIUM.
2. Audit and remove writeToDisk: true from webpack configs — Search codebases for writeToDisk: true in webpack dev configurations. Remove it unless absolutely necessary, as this setting expands the traversal from in-memory assets to the full filesystem.
3. Ensure dev servers bind to localhost only — Verify that webpack-dev-server configs use host: 'localhost' (the default) rather than 0.0.0.0. This eliminates direct network access to the dev server. Enforce via linting rules or PR checks.
4. Block inbound connections to common dev ports at the host firewall — Use host-based firewall rules (iptables, Windows Firewall) to block inbound connections on ports 8080, 3000, 9000 from non-localhost sources. This is defense-in-depth even if a developer overrides the bind address.

Run this on any machine with node and npm installed to check whether project dependencies include a vulnerable version of webpack-dev-middleware. Execute from the project root directory: bash check_webpack_dev_middleware.sh /path/to/project. No special privileges required.

#!/usr/bin/env bash
# check_webpack_dev_middleware.sh — detect vulnerable webpack-dev-middleware
# Usage: bash check_webpack_dev_middleware.sh [project_dir]
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

if [ ! -d "$PROJECT_DIR/node_modules" ]; then
  echo "UNKNOWN — no node_modules found in $PROJECT_DIR. Run npm install first."
  exit 2
fi

PKG="$PROJECT_DIR/node_modules/webpack-dev-middleware/package.json"

if [ ! -f "$PKG" ]; then
  echo "PATCHED — webpack-dev-middleware is not installed in this project."
  exit 0
fi

VERSION=$(node -e "console.log(require('$PKG').version)" 2>/dev/null)
if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not read webpack-dev-middleware version."
  exit 2
fi

echo "Detected webpack-dev-middleware version: $VERSION"

# Compare versions using node semver logic
RESULT=$(node -e "
const v = '$VERSION';
const [major, minor, patch] = v.split('.').map(Number);
if (major <= 4) {
  // v5 branch: anything < 5.3.4 is vulnerable
  // v4 and below: all vulnerable
  console.log('VULNERABLE');
} else if (major === 5) {
  if (minor < 3 || (minor === 3 && patch < 4)) {
    console.log('VULNERABLE');
  } else {
    console.log('PATCHED');
  }
} else if (major === 6) {
  if (minor < 1 || (minor === 1 && patch < 2)) {
    console.log('VULNERABLE');
  } else {
    console.log('PATCHED');
  }
} else if (major === 7) {
  if (minor < 1) {
    console.log('VULNERABLE');
  } else {
    console.log('PATCHED');
  }
} else {
  console.log('PATCHED');
}
" 2>/dev/null)

echo "$RESULT"
if [ "$RESULT" = "VULNERABLE" ]; then
  echo "Action: upgrade to 5.3.4, 6.1.2, or 7.1.0+"
  exit 1
elif [ "$RESULT" = "PATCHED" ]; then
  exit 0
else
  exit 2
fi

Sources

1. GitHub Security Advisory GHSA-wr3j-pwj9-hqq6
2. Snyk Vulnerability DB — webpack-dev-middleware
3. Vicarius PoC Walkthrough
4. Red Hat CVE Entry
5. webpack-dev-middleware npm package
6. webpack Development Guide
7. Vulert CVE-2024-29180 Analysis