CVE-2023-28155 SSRF in the request package and Azure Linux attestation

The Node.js ecosystem’s long-deprecated request package is at the center of a persistent supply‑chain question: CVE‑2023‑28155 describes a server‑side request forgery (SSRF) bypass triggered by cross‑protocol redirects in request versions up through 2.88.x, and Microsoft’s public advisory names Azure Linux as a product that “includes this open‑source library and is therefore potentially affected.” That wording is deliberate and important — it confirms Azure Linux as a known carrier, but it does not technically prove that no other Microsoft product can or does include the same vulnerable library.

Background / Overview​

What is CVE‑2023‑28155?​

CVE‑2023‑28155 is an SSRF mitigation bypass in the widely used Node.js package request. The defect arises when a server controlled by an attacker returns a redirect that changes protocol (for example, HTTP → HTTPS or HTTPS → HTTP). Under certain conditions the request library’s redirect handling can allow that redirect to circumvent SSRF protections, enabling the server to be used as a relay to access internal endpoints that the application intended to block. Public vulnerability trackers and the original GitHub issue filed by researchers describe the technical root cause as a failure in the redirect logic to robustly enforce the same origin / allowed host checks across protocol transitions.
Multiple downstream trackers and CVE aggregators list the affected versions as "through 2.88.1" (some digest pages mention 2.88.2 in downstream packaging metadata), and they consistently note that the project is no longer actively maintained by its original author, which complicates remediation decisions for consumers. That combination — a serious SSRF risk in a deprecated library — is why defenders remain focused on detection and inventory as much as on canonical patching.

Why cross‑protocol redirects matter for SSRF​

SSRF mitigations typically rely on validating the destination host or network address before allowing an application to perform a server‑side request. Redirects add a second dimension: even if the initial destination is benign, an attacker‑controlled endpoint can return an HTTP redirect to an internal-only address (or to a different protocol that the client will treat differently). When redirect handling preserves or transforms sensitive headers, or when origin checks are applied only at the initial request and not reevaluated after redirects, a bypass is possible. CVE‑2023‑28155 exploits precisely that gap in the request package’s redirect logic.

---

Microsoft’s advisory and the Azure Linux attestation​

What Microsoft actually said​

Microsoft’s Security Response Center (MSRC) has used consistent product‑scoped phrasing for a variety of CVEs: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” That sentence confirms Microsoft’s inventory findings for Azure Linux — the Microsoft‑maintained distribution used to build images and container hosts — and signals that Azure Linux operators should treat the package as in‑scope for triage and remediation. Microsoft has also committed to publishing machine‑readable CSAF/VEX attestations and to update CVE mappings as additional Microsoft products are discovered to ship the same upstream component.

Important semantic point: attestation vs exclusivity​

It’s essential to read Microsoft’s sentence precisely. A product‑level attestation is an authoritative statement that the vendor inspected that product and found the component. It is not a categorical declaration that other products are free of the component. In plain terms: Azure Linux is the only Microsoft product Microsoft has publicly attested, so far, to carry this vulnerable library — but that lack of mention is not proof that no other Microsoft products (images, SDKs, agents, containers, Marketplace appliances, CI runners, internal tools, or WSL kernels) could include the same code. Several community analyses have emphasized this distinction and Microsoft itself has said it will update mappings if new carriers are found.

---

Is Azure Linux the only Microsoft product that includes the vulnerable library?​

Short answer: No — or more precisely, “not necessarily.” Azure Linux is the only Microsoft product Microsoft has publicly attested to include the request package for the CVE in question. That attestation is actionable for Azure Linux customers, but it does not prove exclusivity: other Microsoft artifacts could still contain the vulnerable request package until Microsoft either attests those products or customers perform artifact‑level verification themselves. This distinction is the operational heart of the user’s question and the central takeaway for defenders.

Why that distinction matters to enterprises​

• Vendors publish product‑level attestations as an operational convenience: they tell specific customer groups what to prioritize first. That decreases noise and focuses immediate remediation on known carriers.
• Large vendors — particularly ones that ship both Windows and many Linux artifacts, SDKs, and cloud tooling — commonly have thousands of binary artifacts, container images, and auxiliary agents. The same upstream library can appear in dozens of places.
• Automated triage and patching systems that ingest vendor VEX/CSAF data will mark attested products as “affected” and may deprioritize others unless customers perform their own scanning. That makes it risky to assume “not mentioned = not affected.”

---

Evidence and independent corroboration​

To answer the original question responsibly, you need two kinds of evidence:

1. The canonical CVE and vulnerability technical details (NVD/CVE aggregators and the original GitHub thread); and
2. The vendor (Microsoft) attestation and how Microsoft frames its inventory work.

On (1) the request package’s GitHub issue and multiple CVE aggregator pages document the SSRF bypass and the cross‑protocol redirect vector. These records describe the attack mechanism, the affected version range, and the research that led to CVE assignment.
On (2) Microsoft’s Security Update Guide and related public statements (and the WindowsForum analysis of Microsoft’s attestation patterns) make clear that Azure Linux was the product Microsoft inspected and mapped to the CVE at the time of the advisory, while committing to expand the mapping as additional products are identified. That combination gives defenders a clear operational instruction: patch Azure Linux customers now; scan and verify other Microsoft artifacts in your estate to confirm whether they carry the same vulnerable package.

---

Practical guidance: what you should do now​

Whether you run Azure Linux, Windows servers, or mixed cloud workloads, take the following steps immediately. They are written so teams of different sizes can follow them without waiting for additional vendor attestations.

1. If you run Azure Linux images: follow MSRC guidance now​

1. Prioritize patching or rebuilding affected Azure Linux images per Microsoft’s advisory. The MSRC attestation is authoritative for Azure Linux and intended to be acted upon by Azure Linux customers first.

2. Inventory and SBOM your footprint​

1. Scan all container images, virtual machine images, CI runners, build agents, and developer tools for the presence of the request package.
2. Look for package.json/package-lock.json, yarn.lock, pnpm-lock.yaml, and node_modules directories in images and artifacts.
3. Generate or ingest SBOMs where possible; if you already use SBOMs, search for the request package name and for any forks or vendor‑scoped equivalents (for example, @cypress/request). This is a fast way to detect carriers outside Azure Linux.

3. Check cloud images, Marketplace appliances, and WSL/VM images​

1. Do not assume Microsoft’s single‑product attestation covers every image they ship. Inventory your own use of Microsoft‑published artifacts (Marketplace VM images, WSL kernels, container images, Azure DevOps agents, GitHub Actions runner images, and other Microsoft-distributed images).
2. Use offline scanning on downloaded images (e.g., unpack and run automated searches inside tar/OCI image layers) to confirm presence or absence for yourself.

4. Replace or upgrade the dependency where feasible​

• The most straightforward developer remediation is to remove the deprecated request package and migrate to a maintained HTTP client (for example, node‑fetch, axios, or native fetch in recent Node.js LTS versions). Where replacement requires effort, ensure you upgrade to any patched downstream fork/version if one exists, or apply vendor‑supplied mitigations.
• Public trackers list affected request versions up through the 2.88.x series; confirm the exact fixed version in the packaging or vendor advisory for your distribution before updating. If you cannot patch, isolate or restrict the calling service’s network access to limit SSRF impact.

5. Harden SSRF mitigations in code​

1. Treat redirect responses as requiring fresh validation: reapply allowlists / deny‑lists after every redirect, and implement protocol checks that disallow cross‑protocol transitions unless explicitly required.
2. Remove blind forwarding of sensitive headers (Authorization, Proxy‑Authorization, Cookie) across redirects or to third‑party proxies.
3. Apply egress allowlists at the network or proxy layer to block requests to internal IP ranges or metadata endpoints from services that shouldn’t reach them.

6. Hunting and detection tips​

• Search logs for unusual server‑side request behavior to internal-only endpoints originating from services that normally call external APIs.
• Identify long‑lived flows that perform outgoing HTTP(S) requests and look for unexpected status codes like 3xx followed by new hostnames or IPs.
• If you use centralized logging, search for client code patterns or user agents that identify the request library (some older agents include library identifiers). Validate suspicious redirect chains in controlled test harnesses rather than in production.

---

Risks and limitations of vendor‑attested mappings​

False sense of security​

When a vendor publicly attests that a single product includes a vulnerable component, teams that rely solely on vendor‑provided VEX/CSAF data may incorrectly assume other products are safe. Large, diverse vendor portfolios mean the same upstream library often appears in multiple places — sometimes repackaged or vendored into other components. Until a vendor inventories all its artifacts and publishes explicit attestations for each product family, defenders must treat un‑attested artifacts as unverified, not safe.

The problem of deprecated libraries​

A library being “no longer supported by the maintainer” heightens risk: fixes may land in downstream forks, but many packages and images will never be updated. That situation pushes defenders toward either aggressive replacement of the dependency or containment via network controls and runtime mitigations. Public trackers flag the deprecation and affected versions; combine that information with your SBOM to prioritize replacements.

Automation and policy gaps​

Automated tooling that responds to VEX/CSAF input needs conservative defaults: mark attested products as affected and mark non‑attested artifacts as unknown until scanned. Treating unknowns as not affected will create blind spots. If your automation cannot scan all artifacts quickly, prioritize scanning artifacts that expose network egress or that run in privileged environments.

---

Case study: how this plays out in a real‑world environment​

Imagine a cloud tenant with three places the request package could appear: (A) an Azure Linux node image (attested by MSRC), (B) a Marketplace VM image obtained from a third party that was built by Microsoft tooling, and (C) a CI runner image used in company pipelines provided by the vendor. Microsoft’s attestation tags (A) as affected; automated ingesters flag (A) and kick off remediation. If the organization’s triage policy treats the absence of an attestation for (B) and (C) as proof of safety, those artifacts will be left unverified — even though they might contain the same vulnerable code because many build processes reuse upstream packages. The safe course: treat (B) and (C) as unverified and scan them immediately. This pattern is exactly why Microsoft’s attestation phrasing explicitly commits to expanding mappings as more artifacts are checked.

---

When vendor statements can be taken as "complete"​

There are two cases where a vendor attestation can be reliably used as a complete signal:

• The vendor explicitly says “we have exhausted the inventory of all our product families and none except X include the library,” or
• The vendor publishes a comprehensive, machine‑readable SBOM / artifact mapping that covers all product families and images you run.

Microsoft’s current, phased approach — publishing attestations starting with Azure Linux and expanding outward via CSAF/VEX — is pragmatic but not global; it is accurate for the products it names and incomplete for the rest until they are attested. In short: an attestation is authoritative for the product it names. It is not by itself evidence of exclusivity.

---

Final assessment and recommendations​

• Azure Linux is the only Microsoft product Microsoft has publicly attested to include the vulnerable request package for CVE‑2023‑28155 at the time of the advisory. That attestation requires immediate action by Azure Linux customers.
• That attestation is not a technical guarantee that no other Microsoft product can include the vulnerable library. Absence of public attestation should not be treated as proof that other artifacts are unaffected. Customers must perform their own artifact verification or wait for Microsoft to expand its attestations.
• From a defensive perspective the fastest, highest‑value actions are:
  • Patch or rebuild Azure Linux images per Microsoft’s guidance.
  • Generate or ingest SBOMs and scan all images and build artifacts for the request package and for vendor forks such as @cypress/request.
  • Replace deprecated request usages with a maintained HTTP client when feasible; otherwise apply strict SSRF defenses and network egress allowlists.
  • Treat vendor VEX/CSAF outputs as authoritative for the products they name, and treat all other vendor artifacts as unverified until you confirm them via scanning or until the vendor updates the mapping.

---

Closing note on unverifiable claims​

If you encounter claims that “Microsoft has confirmed only Azure Linux is affected” read them cautiously. Microsoft’s public statement confirms only what Microsoft has checked; it does not certify the absence of the vulnerable library from all Microsoft artifacts. That nuance matters operationally for defenders, and it should shape triage policies: treat attested products as confirmed carriers and treat all other artifacts as unverified until proven otherwise.

---

By combining the technical record for CVE‑2023‑28155 (the SSRF bypass in request’s redirect logic) with an understanding of Microsoft’s product‑level attestation practice, security teams can translate vendor statements into concrete, prioritized remediation steps. Patch Azure Linux now, scan everything else, replace or contain deprecated dependencies, and assume “not mentioned” means “not yet checked” rather than “safe.”

---

Source: MSRC Security Update Guide - Microsoft Security Response Center