On March 11, 2024, a path‑traversal vulnerability in the popular Node.js package webpack‑dev‑middleware was made public under CVE‑2024‑29180. The flaw lets an attacker read arbitrary files from the host system when a vulnerable development server is reachable over the network—and the fix shipped in three patch releases the same day.

Microsoft’s Security Response Center has now published an advisory that pinpoints Azure Linux as affected. But the cautious wording in that advisory—and the nature of modern development tooling—means developers, IT admins, and cloud engineers across the Windows ecosystem can’t afford to ignore this one.

What changed: a pre-authentication file read via encoded URLs

The bug sits inside the helper function that maps incoming URLs to files on disk. When webpack‑dev‑middleware is configured with writeToDisk: true—or any setup that serves assets from the physical filesystem—the middleware fails to unescape and normalize URL‑encoded characters like %2e and %2f. An attacker can craft a request such as /..%2f..%2f..%2fetc/passwd, which bypasses the public‑path prefix and reads files outside the project directory.

Security researchers assigned the vulnerability a CVSS 3.1 score of 7.4 (High). The core problem: the server trusts the URL path without decoding it first, then concatenates it with the output directory. No authentication, no special privileges—just a crafted HTTP request.

Affected versions

Major line Vulnerable range Fixed in
5.x < 5.3.4 5.3.4
6.x >= 6.0.0, < 6.1.2 6.1.2
7.x >= 7.0.0, < 7.1.0 7.1.0

Projects that use the default in‑memory filesystem (memfs) are partially shielded, but many real‑world configurations—CI runners, Docker containers with mounted volumes, or any setup that persists assets to disk—restore the attack surface.

What it means for you: it’s not just about Azure Linux

The Microsoft advisory includes a FAQ that has generated confusion: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?” The answer explains that Azure Linux is indeed affected and that Microsoft publishes CSAF/VEX attestations for such products. It adds that if additional products are found to be impacted, Microsoft will update the CVE.

That’s a precise, product‑scoped statement. It means one thing for Azure Linux customers and something very different for everyone else.

For Azure Linux users

This is a clear signal: your distribution contains the vulnerable package. If you’re running Azure Linux container instances, AKS nodes, or virtual machines based on Azure Linux images, you should treat the advisory as a call to action. Microsoft’s machine‑readable attestation gives you a deterministic inventory entry—automate the patch or upgrade as you would for any high‑severity Linux CVE.

For Windows developers and IT teams

The more urgent implication is what the advisory doesn’t say. It does not assert that no other Microsoft product, image, or artifact carries the vulnerable package. webpack‑dev‑middleware is a Node.js development dependency; it can appear in:

  • Azure Marketplace images that bundle Node.js toolchains or sample React/Angular applications.
  • Container images published through the Microsoft Container Registry or used inside Azure Web Apps.
  • Build agents and CI runners in Azure DevOps pipelines (especially self‑hosted agents running on Windows or Linux).
  • Developer VMs provisioned through Azure DevTest Labs or Windows 365 Cloud PCs that have Node.js project files.
  • Windows Subsystem for Linux (WSL) instances where developers run local webpack dev servers.

If a vulnerable dev server is running on a Windows machine—whether directly in Node.js on Windows, via WSL, or inside a Docker container—and that server is reachable from an untrusted network (public Wi‑Fi, a misconfigured home router, or a corporate VPN without proper isolation), the attack works.

For IT administrators, the risk cascades: a developer’s laptop that gets compromised via a development‑server bug becomes a foothold into corporate networks. For cloud operators, an exposed container in a test environment that reads host files could leak credentials or configuration.

How we got here: the gap between package maintenance and vendor attestation

The webpack‑dev‑middleware maintainers fixed the bug within hours of the disclosure in March 2024, and npm advisories have been available since. However, the vulnerability persists in thousands of projects because development dependencies are often left unpinned, and automated dependency scanners are inconsistently applied to non‑production environments.

Microsoft’s Security Response Center began publishing CSAF/VEX attestations in October 2025 as part of a broader transparency push. These machine‑readable documents allow customers to programmatically check whether a specific product (down to the SKU level) contains a known vulnerable component. The Azure Linux advisory is one early output of that program.

The limitation is scope: Microsoft publishes attestations per product family, and the rollout is phased. At the time of the advisory, Azure Linux was the only product family whose inventory had been formally checked and documented for this CVE. The carefully worded FAQ reflects that operational reality—not a definitive statement that all other Microsoft codebases are clean.

Security researchers and independent vulnerability databases unanimously agree on the technical details: the flaw is in the URL‑handling logic of webpack‑dev‑middleware, not in how it is packaged or distributed.

What to do now: stop the bleeding and find every carrier

Action starts with the development team and extends to infrastructure and security operations.

1. Update webpack‑dev‑middleware everywhere

  • In every project that has webpack‑dev‑middleware in package.json or package‑lock.json, upgrade to the fixed version for your major release line (see table above).
  • If you maintain Docker images that include Node.js toolchains, rebuild and push new immutable tags.
  • Add a CI check—for example, npm audit or a Dependabot rule—that blocks builds when any dependency matches known vulnerable versions.

2. Harden running development servers

  • Disable writeToDisk unless absolutely necessary. The default in‑memory mode reduces exposure.
  • Bind dev servers to localhost only. On Windows, webpack‑dev‑server should listen on 127.0.0.1; avoid 0.0.0.0. In WSL, ensure Windows Firewall isn’t allowing inbound connections on the dev server port.
  • Block external access with firewall rules or, at a minimum, require VPN connectivity to reach any dev environment.

3. Inventory your estate

Scan for the vulnerable package using tools that understand Node.js dependencies:

  • Azure and cloud admins: Run container image scanners (Aqua, Trivy, Snyk, Microsoft Defender for Cloud) against all images in your registries. Include Windows‑based containers that might bundle Node.js.
  • CI/CD pipeline owners: Audit build agent configurations and custom runner images. Many agents pre‑install Node.js and might have pulled in a transitive dependency from a sample project.
  • Desktop admins: Use software inventory tools or endpoint detection to locate directories containing node_modules/webpack‑dev‑middleware. On Windows, PowerShell can enumerate project folders: Get-ChildItem -Path C:\\Users -Recurse -Filter \"package.json\" | Select-String \"webpack-dev-middleware\" can give a quick first pass.

4. If you find a compromised server

  • Take the server offline immediately.
  • Preserve web server logs, Docker container snapshots, and package.json files for forensic analysis.
  • Rotate any credentials that were accessible to the server—environment variables, .env files, mounted secrets.
  • Review outbound network logs for signs of data exfiltration (large uploads to unknown IPs, connections to paste sites).

Outlook: vendor attestations are a map, not the territory

Microsoft has committed to updating the CVE if additional products are identified. The CSAF/VEX program will continue to expand, and for Azure Linux customers, the current advisory is an authoritative signal to act. But for everyone else—especially organizations that use a mix of Microsoft and third‑party images, developer tools, and CI pipelines—this CVE is a reminder that supply‑chain risk hides in transient development artifacts.

The practical takeaway is straightforward: treat vendor advisories as high‑quality inputs, not as exhaustive immunity reports. Assume that any environment where Node.js runs could contain the vulnerable package until you’ve scanned it yourself. Update, scan, and lock down exposure—then keep an eye on Microsoft’s update guide for any new product‑level attestations.