webpack-dev-server versions 5

webpack-dev-server ≤ 5.2.5 ships two internal endpoints — /webpack-dev-server/open-editor and the sibling open-in-editor route — with no CSRF token, no Origin/Referer check, and permissive CORS behavior on the developer's loopback listener. When a developer running npm run start visits an attacker-controlled page, that page can issue a cross-origin request that causes the dev server to spawn the developer's configured editor (code, vim, webstorm, etc.) against a file path the attacker chooses. The result is *editor-open thrashing*, potential UI hijack, and in edge cases where the editor CLI parses -- arguments unsafely, further mischief on the developer's own workstation.

Vendor rated this MEDIUM (4.7) with AV:N/UI:R/S:C/C:N/I:N/A:L. The AV:N is technically accurate (the trigger is a network-loaded HTML page) but misleading — the *target* is always localhost on a developer's machine while webpack-dev-server is actively running. The S:C and A:L reflect that the impact escapes the browser sandbox into the OS, but only to the extent of launching an editor. Vendor score is defensible; if anything it slightly overweights the scope change. This is a *developer-hygiene* bug, not a production server bug — webpack-dev-server should never be reachable outside a laptop.

Why this verdict

• Loopback-only target: the vulnerable endpoint lives on the developer's 127.0.0.1 dev server. Deducting ~2 points off the vendor baseline for MAV:L.
• UI:R + tight session window: exploitation requires the developer to visit a hostile page *while* webpack serve is running. Dev servers run for hours, not months — narrow window.
• Browser PNA already mitigates: Chromium's Private Network Access preflight blocks the exact cross-origin → loopback fetch pattern this CSRF depends on, catching the majority of drive-by attempts before they reach step 3.
• Impact ceiling is A:L only: vendor's own vector says no confidentiality or integrity loss. No credential theft, no code execution on build artifacts, no lateral movement.
• Role multiplier — dev workstation: the affected component is *by definition* a developer tool. It never runs on domain controllers, hypervisors, IdPs, CAs, PAM, backup, CI runners (CI uses webpack build, not webpack serve), or edge appliances. The high-value-role catalog does not apply. Floor is LOW.
• Role multiplier — misconfigured host: '0.0.0.0' on shared dev boxes: in rare cases teams bind dev servers to all interfaces on a shared VM. Even then, the chain still ends at editor-open on that box — no fleet or identity impact. Does not raise the floor.

Why not higher?

MEDIUM would require the endpoint to be reachable from a production surface or to affect a role where compromise cascades (CI runner, container registry, IdP). It doesn't — webpack-dev-server is developer-only and the impact ceiling is editor spam. HIGH/CRITICAL are entirely off the table absent a chained editor-CLI RCE, which is a separate CVE against the editor.

Why not lower?

IGNORE is wrong because the fix is trivial (bump to 5.2.6) and organizations with strict SBOM policies will fail builds until the version is bumped. Leaving the vulnerable version in package-lock.json invites drive-by nuisance in dev environments and audit noise. Treat as backlog hygiene, not zero.

1. Bump webpack-dev-server to ≥ 5.2.6 in package.json / lockfiles — This is the actual fix — no mitigation SLA applies at LOW severity, so fold it into the standard 365-day dependency-hygiene cycle (next quarterly dep-refresh sprint). Use npm audit fix or Dependabot/Renovate auto-PRs.
2. Enforce host: '127.0.0.1' in webpack.config.js devServer block — Prevents the dev server from binding to 0.0.0.0 even by accident, so LAN-based attackers on the same coffee-shop Wi-Fi cannot reach it. Add a lint rule or a shared config preset.
3. Ensure Chromium-based browsers on developer laptops have Private Network Access enforcement enabled — PNA blocks the cross-origin → loopback preflight this CSRF depends on. Enforce via chrome://policy (InsecurePrivateNetworkRequestsAllowed=false) through your MDM.
4. Educate developers to run dev servers in a browser profile separate from general browsing — A --user-data-dir profile dedicated to localhost:8080 eliminates the cross-tab CSRF path entirely. Ship as a documented workstation setup step.

Run on any developer workstation or CI SBOM job that has Node.js installed. Invoke from the repo root: bash check-wds.sh /path/to/repo (defaults to current directory). No elevated privileges required — read-only inspection of package-lock.json / yarn.lock / pnpm-lock.yaml.

#!/usr/bin/env bash
# noisgate verification: CVE-2026-14620 — webpack-dev-server CSRF on /open-editor
# Vulnerable: <= 5.2.5    Fixed: >= 5.2.6
# Exit codes: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -u

REPO="${1:-.}"
cd "$REPO" 2>/dev/null || { echo "UNKNOWN: cannot cd to $REPO"; exit 2; }

FIXED_MAJOR=5
FIXED_MINOR=2
FIXED_PATCH=6

vercmp() { # returns 0 if $1 < $2
  IFS=. read -r a1 a2 a3 <<< "$1"
  IFS=. read -r b1 b2 b3 <<< "$2"
  [ "${a1:-0}" -lt "${b1:-0}" ] && return 0
  [ "${a1:-0}" -gt "${b1:-0}" ] && return 1
  [ "${a2:-0}" -lt "${b2:-0}" ] && return 0
  [ "${a2:-0}" -gt "${b2:-0}" ] && return 1
  [ "${a3:-0}" -lt "${b3:-0}" ] && return 0
  return 1
}

found=0
vuln=0

# npm lockfile v2/v3
if [ -f package-lock.json ]; then
  found=1
  versions=$(grep -oE '"node_modules/webpack-dev-server":[[:space:]]*\{[^}]*"version":[[:space:]]*"[0-9.]+"' package-lock.json \
            | grep -oE '"version":[[:space:]]*"[0-9.]+"' | grep -oE '[0-9.]+')
  for v in $versions; do
    if vercmp "$v" "$FIXED_MAJOR.$FIXED_MINOR.$FIXED_PATCH"; then
      echo "VULNERABLE: package-lock.json pins webpack-dev-server $v (< 5.2.6)"
      vuln=1
    fi
  done
fi

# yarn.lock
if [ -f yarn.lock ]; then
  found=1
  versions=$(awk '/^"?webpack-dev-server@/{flag=1} flag && /^  version /{print $2; flag=0}' yarn.lock | tr -d '"')
  for v in $versions; do
    if vercmp "$v" "$FIXED_MAJOR.$FIXED_MINOR.$FIXED_PATCH"; then
      echo "VULNERABLE: yarn.lock pins webpack-dev-server $v (< 5.2.6)"
      vuln=1
    fi
  done
fi

# pnpm-lock.yaml
if [ -f pnpm-lock.yaml ]; then
  found=1
  versions=$(grep -oE 'webpack-dev-server@[0-9.]+' pnpm-lock.yaml | cut -d'@' -f2 | sort -u)
  for v in $versions; do
    if vercmp "$v" "$FIXED_MAJOR.$FIXED_MINOR.$FIXED_PATCH"; then
      echo "VULNERABLE: pnpm-lock.yaml pins webpack-dev-server $v (< 5.2.6)"
      vuln=1
    fi
  done
fi

if [ "$found" -eq 0 ]; then
  echo "UNKNOWN: no lockfile found in $REPO"
  exit 2
fi

if [ "$vuln" -eq 1 ]; then exit 1; fi
echo "PATCHED: all resolved webpack-dev-server versions >= 5.2.6 (or package not present)"
exit 0

Sources

1. webpack-dev-server npm package advisories (Snyk)
2. webpack-dev-server CVE list (CVE Details)
3. webpack org GitHub Security Advisories
4. Chromium Private Network Access spec
5. CWE-352: Cross-Site Request Forgery (CSRF)
6. webpack-dev-server devServer.host configuration docs
7. IBM Security Bulletin — prior webpack-dev-server source exposure CVE (context)
8. FIRST EPSS model overview