Microsoft has confirmed that its Azure Linux distribution contains the widely used but deprecated request Node.js library, making it potentially vulnerable to a server-side request forgery (SSRF) bypass tracked as CVE-2023-28155. The advisory, posted on the Microsoft Security Response Center (MSRC) update guide, is the first public product-level attestation from the company linking this specific open-source component to one of its offerings. But the wording — and what it leaves out — has immediate implications for anyone running Microsoft cloud services, containers, or developer tools.
What CVE-2023-28155 Actually Does
The vulnerability resides in the request package’s handling of HTTP redirects that switch protocols — for instance, from HTTP to HTTPS or vice versa. When an attacker controls a server that returns such a redirect, the library can be tricked into following the redirect to an internal address, even when the initial request was meant to be restricted. Because the redirect logic does not re-validate the target host against the original allowed list after a protocol change, an SSRF bypass is possible.
Public records show that all versions up to and including 2.88.x are affected. The original GitHub issue and multiple CVE aggregators describe the technical root cause: cross-protocol transitions are not properly gated during redirect handling. The request package has been deprecated for years, and its original maintainer no longer provides updates. That leaves millions of downstream projects without a canonical patch — a scenario that forces adopters to either migrate to a different HTTP client or implement their own workarounds.
Microsoft’s Advisory: What It Says and What It Doesn’t
On its update guide, Microsoft states: “Azure Linux includes this open-source library and is therefore potentially affected by this vulnerability.” The phrasing is deliberate. It confirms that the company’s own inventory work has identified the request package inside Azure Linux images, and it instructs Azure Linux customers to treat the CVE as applicable to their deployments. Microsoft also commits to updating the CVE mapping if other products are found to carry the same library, noting that it began publishing machine-readable CSAF/VEX attestations in October 2025.
Crucially, the advisory does not say that Azure Linux is the only Microsoft product that contains the vulnerable library. It is a product-level attestation — a positive statement about one specific artifact. For every other Microsoft-distributed image, container, SDK, build agent, or tool, the status remains unverified unless Microsoft explicitly updates the record. Security teams should not interpret the lack of an attestation as proof of safety. The most prudent reading is: “Azure Linux is a known carrier; all other Microsoft artifacts are unconfirmed and must be scanned.”
What It Means for You
The impact varies by role, but the common thread is a need for independent verification.
For Azure Linux administrators: Microsoft’s advisory is authoritative. If you run Azure Linux — whether as a container host, AKS node image, or standalone VM — prioritize patching or rebuilding images per the guidance. The MSRC attestation is intended to be acted on immediately.
For Windows server and hybrid cloud administrators: Do not stop at Azure Linux. Scan every container image, virtual machine image, CI runner, DevOps agent, and developer tooling you use that might be Node.js-based. Check package.json files, lock files, and node_modules directories for the request package or its forks (like @cypress/request). Many Microsoft-published artifacts, including Marketplace appliances, WSL kernels, and GitHub Actions runner images, could bundle the same deprecated library.
For developers and engineering leads: Review your own projects for dependencies on request. If you find it, replace it with a maintained HTTP client such as node-fetch, axios, or the native fetch API available in recent Node.js LTS releases. Where replacement is not immediately possible, enforce strict SSRF protections: re-validate every redirect target against an allowlist, strip sensitive headers (Authorization, Cookie) when following redirects, and apply network egress filtering to block requests to internal IP ranges.
For security operations and compliance teams: Update your VEX/CSAF ingestion policies. Treat any product that lacks an explicit vendor attestation as unverified, not unaffected. Integrate SBOM scanning into your CI/CD pipelines and registry checks to catch the request package wherever it hides. Hunt for unusual redirect behavior in your server-side request logs — look for 3xx responses followed by connections to internal subnets or metadata endpoints.
How We Got Here
CVE-2023-28155 was assigned in 2023 after researchers discovered the bypass in request’s redirect logic. At that point, the library was already effectively abandonware: its creator had archived the repository, and no official update would be forthcoming. The situation is not unique; thousands of organizations still depend on unmaintained open-source packages because migration is costly and the risk seems abstract until a high-profile CVE forces action.
Microsoft’s move to publish CSAF/VEX data in October 2025 marked a significant shift toward transparency. By creating machine-readable attestations, the company gave defenders a way to programmatically determine which products are officially affected. However, the initial rollout focuses on Azure Linux and will expand outward over time. In the interim, the gap between what Microsoft has checked and what actually exists in the wild remains a supply-chain blind spot. Past SSRF incidents (such as the 2019 Capital One breach, which exploited a server-side request flaw to access internal metadata) illustrate how a single bypass can escalate to widespread cloud compromise, making proactive inventory essential even when vendor attestations are incomplete.
What to Do Now
These steps apply whether you run a single server or a fleet of cloud workloads.
-
Patch or rebuild Azure Linux images immediately. If Microsoft’s advisory names your distribution, follow it. Update packages or switch to a newer image that omits the vulnerable library.
-
Generate or ingest an SBOM for every Node.js artifact you run. Use tools like Syft, Trivy, or GitHub’s dependency submission API to create a list of all components. Search for “request” and any known forks. If you already have SBOMs, filter for the package name and affected version range.
-
Migrate away from the request package. For any active project, replace request with a modern HTTP client that is actively maintained. This is not a quick fix, but it is the only permanent solution. Node.js 18 and later include a stable fetch implementation, reducing the need for third-party libraries altogether.
-
Harden SSRF protections in code. Until migrations are complete, add defensive layers:
- Re-validate redirect targets against an allowlist after every hop.
- Disable automatic cross-protocol redirects unless explicitly needed.
- Remove authorization headers and cookies when following redirects to untrusted hosts.
- Use network controls to block outbound traffic to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata endpoints (169.254.169.254). -
Scan unverified Microsoft artifacts yourself. Do not wait for an MSRC update. Download container images and VM templates you use, unpack them, and search for package.json files or node_modules containing request. This includes Azure DevOps agents, GitHub-hosted runners, and any Marketplace appliance that bundles Node.js.
-
Monitor logs for exploitation attempts. Look for sequences where an application makes an outgoing HTTP(S) request, receives a redirect, and then attempts to connect to an internal address. Correlate user agents that identify older Node.js HTTP clients if possible. Test suspicious redirect chains in an isolated environment.
Outlook
Microsoft’s commitment to expanding its CSAF/VEX coverage will reduce some of the uncertainty over time. Expect updates to the CVE entry as more products are formally attested. In the broader ecosystem, the request package’s deprecation highlights a recurring theme: the most dangerous vulnerabilities often live in the unglamorous corners of the supply chain. The immediate fix for CVE-2023-28155 is straightforward, but the operational lesson — never assume a vendor’s single-product attestation covers your entire estate — will outlast this particular CVE. Continue scanning, verify before trusting, and replace deprecated dependencies before they become emergencies.