Microsoft’s Security Response Center has publicly attested that its cloud-optimized Azure Linux distribution carries a vulnerable version of follow-redirects—a widely used Node.js library—exposing systems to potential credential theft through malicious redirects. The vulnerability, designated CVE-2024-28849, was patched upstream more than a year ago, but Microsoft’s advisory, published alongside its new machine-readable vulnerability disclosure framework, stops short of clearing other Microsoft products. That means if you run anything from Azure DevOps agents to custom Node workloads on Windows, you’ll need to verify for yourself whether the flawed component lurks inside your stack.

The Vulnerability at a Glance

CVE-2024-28849 stems from a logic flaw in follow-redirects, a Node.js package that handles HTTP(S) redirects. In all versions prior to 1.15.6, the library would correctly strip Authorization and Cookie headers during cross-domain redirects but fail to remove the Proxy-Authorization header. An attacker controlling a legitimate redirect target—or exploiting an open redirect flaw—could trick a Node.js application into forwarding proxy credentials to an unauthorized third party.

This isn’t a hypothetical risk. follow-redirects is a transitive dependency of axios, one of the most popular HTTP client libraries for Node.js, meaning it’s pulled into thousands of projects, build tools, and cloud agents. A single unpatched instance in a CI/CD pipeline or container image can expose proxy-authenticated internal networks to credential leakage.

The upstream fix arrived on March 14, 2024, with the release of follow-redirects 1.15.6. The patch ensures that Proxy-Authorization headers are now removed alongside other sensitive headers during redirects to a different domain. Despite the patch availability, lingering installations continue to pose a threat—a scenario Microsoft’s advisory now brings into sharp focus for Azure Linux users.

What Microsoft’s Advisory Does (and Doesn’t) Say

On its CVE-2024-28849 page, Microsoft’s MSRC states plainly: “Azure Linux includes this open-source library and is therefore potentially affected.” This is a product-level inventory attestation—Microsoft has inspected Azure Linux images and found follow-redirects present. It is authoritative for that product family: if you use Azure Linux, treat your images as vulnerable and act immediately.

But the wording is deliberately scoped. It does not declare that no other Microsoft product ships the library. Instead, Microsoft commits to a process: if additional products are identified as carriers, the CVE will be updated. This approach, introduced alongside the company’s Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX) initiative that began rolling out in October 2025, aims to provide structured, machine-readable attestations—starting with Azure Linux.

The practical upshot? Absence from the advisory is not proof of immunity. Many Microsoft artifacts—SDKs, Azure DevOps build agents, Electron-based tools like Visual Studio Code, and even container images for services like Azure Functions—could theoretically bundle Node.js dependencies. Until Microsoft expands its attestation list, every other Microsoft product remains unverified.

How This Impacts You—Depending on Your Role

For Azure Linux Administrators

If you deploy Azure Linux VMs, container hosts, or images from the Azure Marketplace, you are running a confirmed carrier of the vulnerable component. Microsoft’s attestation puts the onus squarely on you to patch or replace affected instances. Check your image repositories, running nodes, and any automated scaling configurations. The fix is a dependency update to follow-redirects 1.15.6 or newer, but on a distro like Azure Linux, the surest path is to deploy updated base images from Microsoft once they become available, or rebuild your own images with the patched package.

For Windows and Node.js Developers

Your development machine or build server may not run Azure Linux, but you almost certainly use Node.js. If your application depends on axios or any package that pulls in follow-redirects, you need to audit your project’s dependency tree. Even if you don’t use proxy authentication directly, a misconfigured corporate proxy or a compromised redirect could still expose credentials to an external host. Run a quick check in your project root:

  • npm ls follow-redirects --all
  • yarn why follow-redirects
  • pnpm why follow-redirects

If you see a version below 1.15.6, upgrade your consuming package immediately. For axios, that often means bumping to a recent release that pins follow-redirects 1.15.6 or later.

For IT Managers Overseeing Mixed Environments

Your organization likely has footguns you haven’t inventoried yet. CI/CD runners—even Microsoft-hosted ones—often execute Node.js workloads. Build containers, test frameworks, and internal tooling can all silently embed the flawed library. Without your own Software Bill of Materials (SBOM) for every artifact, you cannot trust vendor attestations alone. Prioritize scanning these areas:

  • Container images used in Azure Kubernetes Service (AKS) or Azure App Service
  • Self-hosted and Microsoft-hosted build agents in Azure DevOps or GitHub Actions
  • Electron-based Microsoft products (Teams, VS Code) that may bundle Node.js dependencies internally
  • Any third-party Azure Marketplace images that layer on Node.js

The absence of an explicit Microsoft attestation for these products means you must treat them as potentially affected until proven otherwise.

The Timeline: From Upstream Fix to Microsoft’s Attestation

CVE-2024-28849 showcases the long tail of open-source vulnerabilities in enterprise software. The flaw was disclosed and fixed in March 2024, with details published in the National Vulnerability Database (NVD) and the GitLab Advisory Database. For over a year, any team that kept its dependencies updated was protected.

However, many organizations—especially those running curated Linux distributions like Azure Linux—rely on their vendor to backport fixes or issue security advisories. Microsoft’s MSRC entry for this CVE didn’t appear until later, postdating the company’s October 2025 launch of CSAF/VEX attestations. That timing explains why the advisory is narrowly scoped to Azure Linux: it’s the first product family in a phased rollout that will eventually cover more Microsoft software.

This delay between upstream patch and vendor advisory is common, but it leaves a dangerous gap. Malicious actors often reverse-engineer fixes to exploit unpatched installations. The fact that Microsoft’s advisory comes long after the public fix means the window for zero-day-style attacks on Azure Linux (or any other unverified Microsoft product) was open for months—unless you were already scanning your own dependencies.

Action Plan: How to Hunt for CVE-2024-28849 in Your Environment

You can’t wait for Microsoft to tell you everything that’s vulnerable. Here’s a practical plan to root out the flaw in your own infrastructure.

Verify Your Azure Linux Instances

Start with the known knowns. List all Azure Linux VMs, images, and container nodes in your subscription. For each, check whether follow-redirects is installed and which version:

  • Connect to the instance and run npm ls follow-redirects --all if Node.js is present.
  • Inspect any pre-installed Node.js tools: some Azure Linux images bundle the Azure CLI or other utilities that depend on Node.js packages.
  • If scanning container images, use a tool like Trivy or Anchore that reports transitive npm dependencies. For example: trivy image --vuln-type library <image>.

If you find the package, upgrade it immediately or deploy a patched image. Rotate any proxy credentials used in that environment if there’s evidence of redirect-based logging anomalies.

Scan Your Own Code and Containers

Don’t assume your internal applications are clean. Generate an SBOM for every Node.js project and container image you build. Tools like Syft can produce CycloneDX JSON output for Docker images and source repositories:

syft <image> -o cyclonedx-json=sbom.json
jq '.components[] | select(.name=="follow-redirects")' sbom.json

Once you have an SBOM, you can automate checks for follow-redirects versions < 1.15.6. Integrate this into your CI/CD pipeline to catch vulnerable dependencies before they reach production.

Consider the Unseen Dependencies

Some artifacts bundle Node.js in a way that escapes standard package scans. Electron apps, for example, often ship compressed .asar archives containing all their dependencies. Microsoft Teams, VS Code, and other Electron-based tools may embed follow-redirects internally. While these have their own update mechanisms, a vulnerable version in a desktop app could still leak proxy credentials if the app makes HTTP requests through a corporate proxy. Check your fleet’s installed versions and look for any security advisories from those product teams.

Azure DevOps and GitHub Actions runners also warrant scrutiny. If you use Microsoft-hosted agents, your build scripts might download and execute npm packages that include a vulnerable follow-redirects. The runner environment itself may not be affected, but your build artifacts can become carriers. Audit your pipeline lockfiles.

What Microsoft Promises Next

Microsoft’s October 2025 rollout of CSAF/VEX attestations is a step toward automated vulnerability management at scale. Under the program, each Microsoft product will receive a structured statement: “Known Affected,” “Not Affected,” or “Under Investigation.” This feeds directly into enterprise vulnerability scanners that can then prioritize patching without manual research.

For CVE-2024-28849, Microsoft has committed to updating the CVE page if additional products are found to carry follow-redirects. But the timeline is uncertain. Until then, the burden of verification falls on you. Enterprise security teams should press Microsoft for per-product SBOMs or at least a public index of common artifacts and their dependency versions. Such transparency would dramatically shrink the gap between upstream fixes and customer action.

The Bigger Picture

CVE-2024-28849 is not the most critical vulnerability of the year—it has a 6.5 CVSS score—but it epitomizes the dependency hell of modern software supply chains. A tiny library maintained by a handful of open-source contributors can, through transitive inclusion, end up inside a major cloud operating system and an array of developer tools. When a vendor issues a scoped advisory, it’s a prompt, not a permission slip to ignore the rest of your stack.

Months from now, Microsoft’s CSAF/VEX program may fill in the gaps. But today, the most secure strategy is to assume nothing. Scan every artifact you run, from the cloud VM to the desktop IDE. Because when it comes to credential leaks, one overlooked dependency can open a door to your entire network.