CVE-2024-28849 Explained: Azure Linux Attestation and Follow Redirects Risk

Microsoft’s public advisory for CVE-2024-28849 names the Node.js package follow-redirects and confirms that Microsoft’s Azure Linux distribution includes the vulnerable component — but that attestation is a scoped inventory statement, not an assurance that no other Microsoft product could also ship the same library.

Background / Overview​

The vulnerability tracked as CVE-2024-28849 concerns the Node.js package follow-redirects, a widely used helper that implements HTTP(S) redirect-following behavior for Node applications (and is embedded as a dependency of many higher-level libraries such as axios). In versions prior to 1.15.6, the library failed to remove the Proxy-Authorization header on cross-domain redirects, which can cause proxy credentials to be forwarded to an unintended destination and produce a credential-leakage risk. The issue was publicly disclosed in March 2024 and addressed in the upstream package by version 1.15.6.
Microsoft’s Security Response Center (MSRC) has an entry for the CVE that explicitly states: “Azure Linux includes this open-source library and is therefore potentially affected,” and follows that with a process-oriented commitment to publish machine-readable CSAF/VEX attestations (starting with Azure Linux) and to update the CVE/VEX mapping if additional Microsoft products are identified as carriers. That wording is deliberate and operational: it confirms what Microsoft has inventory-checked so far and explains how Micromapping in the future.

---

What the MSRC wording actually means​

Product-level attestation, not exclusivity​

When Microsoft says “Azure Linux includes this open-source library and is therefore potentially affected,” the statement should be read as a product-level inventory attestation — Microsoft inspected the Azure Linux images and found instances of the implicated library. That attestation is authoritative for Azure Linux (it means Azure Linux customers should treat the package as in-scope), but it is not a categorical declaration that other Microsoft products do not include the same package. In short: Azure Linux is the only Microsoft product Microsoft has pclude follow-redirects for this CVE so far, but that absence of mention is not proof of absence elsewhere.

Why vendors use this phrasing​

There are practical constraints and operational reasons for this approach:

• Inventorying every Microsoft product and every embedded dependency takes time. Microsoft’s VEX/CSAF program explicitly begins with one product family (Azure Linux) as a practical way to roll out machine-readable attestations at scale.
• A product-level attestation reflects what was observed in a particular build or image — it does not (and cannot) prove that the same upstream artifact does not appear in other, independently-built Microsoft artifacts, containers, agents, or SDKs.
• Microsoft’s promise to update the CVE/VEX entry if additional products are found to carry the component creates an audit trail and a mechanism for future expansion of the mapping; it doesn’t convert the initial attestation into an exclusivity guarantee.

---

Independent verification of the vulnerability and upstream remediation​

The technical findings about the vulnerability and the upstream remediation are independently recorded in multiple places: the NVD (NIST), published advisories (GitLab Advisory Database), and vendor/third-party vulnerability databases. These sources confirm:

• The root cause: follow-redirects kept the Proxy-Authorization header across cross-domain redirects while clearing Authorization and Cookie headers, leading to potential exposure of proxy credentials.
• The fix: the issue was fixed upstream and users are advised to upgrade to follow-redirects 1.15.6 or later.

Those independent records allow defenders to confirm what changeversions are safe to consume.

---

Short answer to the user’s question​

No: Azure Linux is not necessarily the only Microsoft product that includes the vulnerable open‑source library, but it is the only Microsoft product Microsoft has publicly attested (via MSRC and VEX/CSAF) to include the component for CVE-2024-28849 at the time of the advisory. Treat the MSRC attestation as authoritative for Azure Linux; treat other Microsoft artifacts as unverified until Microsoft expands its attestations or until you perform your own artifact-level verification.

---

Why this distinction matters to defenders​

A vendor naming a single product as a confirmed carrier has three practical consequences:

• It directs immediate remediation effort (patching or rebuild) to a known affected product family — customers of that product should act first.
• It reduces noise for organizations that rely on vendor-provided VEX/CSAF data to automate triage: if Microsoft has marked only Azure Linux as “known affected,” automated systems can deprioritize Microsoft products that are attested as “not affected” or “not listed.”
• It does not mean that other Microsoft artifacts (agents, SDKs, cloud services, container images, developer tools, CI runners, etc.) could not include the same vulnerable package — they could, and those artifacts must be verified by artifact-level scanning or Microsoft’s future attestations.

In short: Microsoft’s attestation narrows the immediate work for Azure Linux customers, but it does not eliminate the need for inventory verification across your environment.

---

How to verify whether other Microsoft products or artifacts in your environment include follow-redirects​

If you or your organization consume Microsoft artifacts and want to confirm whether those artifacts carry the vulnerable package, follow these practical, artifact-level steps.

1. Scan your Node builds and container images​

• Run dependency discovery inside each Node.js project:
• npm: npm ls follow-redirects --all
• yarn: yarn why follow-redirects
• pnpm: pnpm why follow-redirects
• Inspect your application lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) for follow-redirects entries and version ranges.
• For containers, extract the filesystem and run the above scans against the node_modules directories, or use a container security scanner that reports transitive npm dependencies (Trivy, Anchore, Snyk, etc.).

These commands show whether follow-redirects is present as a direct or transitive dependency inside a build or image.

2. Generate and consume SBOMs​

• Produce Software Bill of Materials (SBOMs) for images and artifacts using tools such as Syft or the Node.js packagers that support CycloneDX output.
• Search the SBOM for package name “follow-redirects” and check versions.
• If you already ingest SBOMs into your vulnerability management platform, add a rule to highlight follow-redirects versions < 1.15.6.

SBOMs reduce manual lookup and are the recommended artifact-level source of truth for dependency presence.

3. Scan binary blobs and installer packages​

• For distributed binaries that might bundle Node runtimes and packages (think developer tools, CLI installers, or packaged Electron apps), use a tool that performs filesystem and archive scanning (unpack installers and search for node_modules, .asar archives, or embedded tarballs).
• For Electron-based Microsoft products or third-party apps, search for follow-redirects inside app.asar or similar bundling formats.

4. Audit CI/CD pipeline dependencies and builders​

• Check images and agents used in CI (self-hosted runners, Microsoft-hosted runners, containerized build environments) for presence of follow-redirects. A build that runs npm install inside a builder that includes an older follow-redirects could introduce the vulnerable component into produced artifacts.
• If you use Microsoft-hosted runners or Azure DevOps agents, verify whether your CI templates rely on base images that include Node dependencies; treat those base images as inventory artifacts to be scanned.

5. Use code search in source repositories​

• Search your source and dependency repositories for references to “follow-redirects” or to axios versions that depend on it.
• If you manage a large mono-repo or many microservices, consider automated code-search tools or repository scanning (GitHub code search, grep on clones) to find occurrences quickly.

These verification steps help you find whether the vulnerable package exists in your artifacts regardless of vendor attestation.

---

Mitigation and remediation guidance​

If you find follow-redirects present in any artifact in your environment, prioritize remediation according to exposure and risk.

Immediate actions​

• Upgrade the library: ensure follow-redirects is updated to version 1.15.6 or later wherever it appears. For projects that depend on axios, bump axios (or the consuming package) to a version that brings in follow-redirects 1.15.6+.
• Rebuild images and redeploy: after dependency updates, rebuild any affected container images, binaries, or installers and replace running artifacts.
• Rotate proxy credentials if there is evidence of exposure: if any logs, proxy telemetry, or IDS indicate that credentials might have been forwarded to an untrusted host during a redirect, rotate affected credentials and investigate for misuse.

Compensating controls (short term)​

• Harden redirect handling in client code: where feasible, avoid following redirects automatically when proxy authentication is in use; ensure per-request options or application logic strips sensitive headers on redirects.
• Limit proxy credential scope: prefer ephemeral or narrowly-scoped proxy credentials so that if they are exposed they present limited risk.
• Network controls: use egress filtering and allowlists so that if a request is redirected to an untrusted host the network will block exfiltration of sensitive headers at the perimeter.

Longer-term hygiene​

• Adopt SBOM generation and VEX/CSAF ingestion so that vendor attestations are automatically consumed and mapped to locally generated inventory. Microsoft’s VEX program is designed to help here, but local proof via SBOM is still necessary.
• Automate dependency updates and rebuilds for production artifacts so that patched upstream versions propagate quickly through your delivery pipeline.

---

Specific checks for Microsoft-managed environments and customers​

If you run Azure services or consume Microsoft-managed artifacts, apply these focused checks:

• Azure Marketplace and VM images: scan Marketplace VM images and private images for follow-redirects before provisioning; Microsoft has attested Azure Linux images, so prioritize those images for patching and reimaging.
• Azure DevOps and GitHub Actions: inspect build agents and any Microsoft-published actions that execute Node workloads. If you rely on Microsoft-hosted runners, validate whether your build steps or action inputs pull vulnerable dependencies into the build artifacts.
• Cloud-native workloads: scan deployed containers in AKS or App Service for the package and apply image updates as needed.

These are practical, environment-specific actions that complement the general remediation steps above.

---

What Microsoft could do (and what they already committed to)​

Microsoft’s MSRC has already taken two concrete steps that help defenders:

• They published a product-scoped attestation naming Azure Linux as a carrier for the component in question. That gives Azure Linux customers an immediate, vendor-backed signal for remediation.
• Microsoft announced a phased rollout of machine-readable VEX/CSAF attestations (starting October 2025) to provide a structured mechanism to indicate which products are “Known Affected,” “Not Affected,” or “Under Investigation.” This program will allow automated signals to flow into enterprise vulnerability management systems.

To further reduce operational ambiguity, Microsoft could:

• Speed up inventory scans across other product families and publish expanded VEX attestations sooner.
• Publish per-artifact SBOMs or provide an index of common Microsoft SDKs and images with their dependency versions to make triage faster for enterprise customers.
• Offer guidance for customer administrators that explains when an MSRC product attestation should be treated as exhaustive versus when artifact-level verification is still required.

These suggestions simply align with the expectations many igh-visibility vendors who ship many disparate artifacts.

---

Practical detection examples (commands and patterns)​

Below are quick, repeatable checks you can run as part of a triage:

• Node project: list transitive dependencies
• npm ls follow-redirects --all
• yarn why follow-redirects
• pnpm why follow-redirects
• Container image: enumerate node modules (example using docker)
• docker run --rm -it --entrypoint /bin/sh <image>
• find / -type d -name "node_modules" -prune -exec sh -c 'ls -1 {} | grep follow-redirects && echo {}' \;
• SBOM search (CycloneDX JSON produced by syft)
• syft <image> -o cyclonedx-json=sbom.json
• jq '.components[] | select(.name=="follow-redirects")' sbom.json
• CI artifacts: scan your build logs and lockfiles for “follow-redirects” and check the resolved version in the lockfile.

If you need to prioritize, focus on internet-facing clients and artifacts that use proxies with per-credential authentication; these are the highest-risk carriers for Proxy-Authorization leakage.

---

Risks and limitations — what to watch for​

• False assurance from attestation absence: as emphasized above, the absence of a Microsoft attestation for a product does not prove it’s not affected — only that Microsoft has not yet publicly documented that product as including the component. Treat un-attested artifacts as unverified until checked. /archive.ph/2025.12.05-202816/https%3A/msrc.microsoft.com/update-guide/vulnerability/CVE-2025-38709)
• Transitive dependencies: follow-redirects is commonly a transitive dependency (for example via axios). Patching direct dependencies may not be sufficient; ensure transitive dependency resolution upgrades follow-redirects to the fixed version.
• Rebuilt binaries: some vendors or teams may embed Node modules into binary distributions or bundle them into installers; these bundled occurrences can be missed by a simple source-level search and require unpacking and scanning of the distribution artifacts.

Flag these conditions during triage and treat them as higher-risk until provenance is clear.

---

Conclusion​

Microsoft’s public note that “Azure Linux includes this open-source library and is therefore potentially affected” is correct and operationally useful: it tells Azure Linux customers to treat follow-redirects as in-scope for CVE-2024-28849 and it points to Microsoft’s ongoing CSAF/VEX work as the mechanism that will document additional product mappings in the future. However, that wording does not constitute an exclusivity guarantee that no other Microsoft product ships the vulnerable package. Defenders must therefore perform artifact-level verification across their estate — scanning source repositories, build images, deployed containers, and third-party binaries — and upgrade any instances of follow-redirects to version 1.15.6 or later.
The practical takeaway for security teams is straightforward: prioritize Azure Linux images (as Microsoft indicated), but do not stop there — search your own artifacts, rebuild and redeploy with patched dependencies, and ingest vendor VEX attestations as they appear to automate future triage.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center