Microsoft’s Security Response Center (MSRC) published an advisory for CVE-2024-28757, a high-severity XML External Entity (XXE) expansion flaw in the libexpat library, on its update guide. The advisory explicitly names Azure Linux as a product that includes the vulnerable component and is therefore potentially affected. But the wording stops short of clearing any other Microsoft product, leaving administrators to hunt for exposure across their entire Microsoft fleet.

The Vulnerability at a Glance

XML External Entity expansion attacks – often called “billion laughs” attacks – are a classic denial-of-service technique. An attacker crafts a malicious XML document with nested entity definitions that expand exponentially when parsed, consuming available memory, CPU, or stack space until the application crashes or becomes unresponsive. CVE-2024-28757 targets a specific code path in libexpat, the compact stream-oriented XML parser written in C that ships in countless operating systems, packages, and commercial products.

The flaw was disclosed in March 2024. It affects libexpat versions through 2.6.1 when an application calls XML_ExternalEntityParserCreate to generate an isolated parser for external entities. That isolated context could bypass the normal entity-expansion limits, allowing a crafted DTD to trigger unbounded expansion. The upstream Expat project fixed the issue in version 2.6.2 by ensuring the external parser path enforces expansion limits; distribution maintainers have since shipped patched packages.

Microsoft’s advisory mirrors the technical description from the National Vulnerability Database. It confirms that Azure Linux, which bundles libexpat in its package repositories, is subject to this vulnerability. The fix: update libexpat to 2.6.2 or later – or apply the distribution-specific security update that Microsoft has guided Azure Linux users to deploy.

Who Is Affected and How to React

Azure Linux customers: patch now

If you run Azure Linux virtual machines, container hosts, or any image derived from Azure Linux, you’re in the confirmed blast zone. Apply the latest Azure Linux updates immediately. Query your package manager: rpm -q expat or tdnf list installed expat – if the version is ≤ 2.6.1, you’re vulnerable. Upgrade to the patched package that ships with recent Azure Linux releases.

For everyone else: verify, don’t assume

Here’s the critical nuance in Microsoft’s advisory. The MSRC FAQ line reads: “One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date … Microsoft is committed to transparency … which is why we began publishing CSAF/VEX in October 2025.” It then states that Azure Linux includes the open-source library and is potentially affected. Crucially, it adds: “If impact to additional products is identified, we will update the CVE to reflect this.”

That is not a blanket statement of safety for other Microsoft products. It is an attestation that Azure Linux is affected, paired with a promise to expand the CVE mapping if other products are found to contain the vulnerable component. Microsoft has not yet published machine-readable attestations (CSAF/VEX) for products beyond Azure Linux that might also embed libexpat. The absence of an advisory for Windows, WSL images, container base images, or management agents does not mean those products are free of the flaw – it means they haven’t been fully inventoried and attested to yet.

In practical terms, treat any non-Azure-Linux Microsoft artifact as unverified. That includes:

  • WSL distributions: The prebuilt WSL images Microsoft distributes (Ubuntu, Debian, etc.) often include libexpat packages. Check your installed WSL instances.
  • Container images: Many Microsoft base images for Linux containers (e.g., in Azure Container Registry or on Docker Hub) incorporate standard Linux packages, including libexpat.
  • Agent and tooling binaries: Monitoring agents, backup tools, SDK components, and Azure-connected services that run on Linux may statically link or bundle libexpat.
  • Windows build environments: Cygwin, MSYS2, and other compatibility layers on Windows can ship libexpat, potentially exposing Windows-hosted services that parse XML from untrusted sources.
  • Embedded and appliance images: Azure Stack HCI, Azure Percept, and other specialized images that include Linux subsystems may also be at risk.

Why This Advisory Feels Incomplete

Microsoft’s approach – publish an authoritative mapping for the product you’ve fully inventoried and then expand – is operationally pragmatic. It gives Azure Linux customers an immediate, actionable signal. It also avoids the embarrassment of claiming safety where it hasn’t been proven. However, the tradeoff is that defenders must fill the gap with their own detective work.

Large vendors ship dozens or hundreds of binary artifacts. Fully cross-referencing them against every open‑source CVE is a monumental task. Microsoft began publishing CSAF/VEX documents only in October 2025, so the coverage is still maturing. Until a product appears in a CSAF/VEX feed with a “not affected” status for CVE-2024-28757, you cannot rely on silence as proof.

The forum community and independent analysts have consistently flagged this same distinction: Microsoft’s attestation is authoritative for the products it explicitly names, but it is not a global inventory. Attackers don’t need every product to be vulnerable – they need just one reachable service in your environment that parses attacker-controlled XML with libexpat ≤ 2.6.1.

Your Action Plan: Find Every Copy of libexpat

1. Inventory all Linux instances

Run these commands on every Linux VM, container, and WSL environment you manage:

  • RPM-based systems (Azure Linux, RHEL, Fedora): rpm -qa | grep -i expat
  • Debian-based systems (Ubuntu, Debian): dpkg -l | grep -i expat or apt list --installed 2>/dev/null | grep expat
  • Generic package scan: find / -name \"libexpat*\" 2>/dev/null (use with caution on large filesystems)

If you find libexpat version ≤ 2.6.1, flag the host for patching.

2. Scan container images

Use a container image scanner that reports package versions (e.g., Trivy, Docker Scout, Aqua, or the scanner built into your CI/CD pipeline). Look for the expat or libexpat package. For a quick manual check, run:

docker run --rm <image> sh -c \"dpkg -l 2>/dev/null | grep expat || rpm -qa 2>/dev/null | grep expat\"

Rebuild images that contain vulnerable libexpat with patched base images.

3. Examine statically linked binaries

On Linux, you can use strings <binary> | grep -i expat to see if libexpat symbols are present, or ldd <binary> | grep expat to check dynamic linking. For Windows binaries that might bundle Expat (e.g., through Cygwin or MSYS2), inspect the installation directory for libexpat*.dll or search the file system.

4. Check Windows development environments

If your developers use Cygwin or MSYS2, run the package manager command (e.g., cygcheck -c | grep expat or pacman -Qs expat) to see the installed expat version. These environments can sometimes expose Windows services that parse XML with the vulnerable library.

5. Temporary mitigations while you patch

If you cannot immediately update libexpat, reduce the attack surface:

  • Disable external entity parsing in your XML processing code. If your application does not require external entities, set the parser to reject them. In libexpat, this can be achieved by not using XML_ExternalEntityParserCreate and ensuring XML_SetEntityDeclHandler is not set to allow custom entities.
  • Apply resource limits: Use Linux control groups (cgroups) or ulimit to cap the memory and CPU a process can consume, limiting the blast radius of an XXE attack.
  • Deploy a web application firewall (WAF) that can block XML payloads containing suspicious entity definitions.
  • Filter input: Reject XML documents that contain DOCTYPE declarations with entity definitions if your service does not need them.

6. Monitor for Microsoft updates

Watch the MSRC advisory page for CVE-2024-28757 and Microsoft’s CSAF/VEX feeds (published in the Security Updates API). As Microsoft inventories more products, it will update the CVE mapping. A new entry in the CSAF/VEX feed for a product you use is the definitive signal to either patch or relax.

What’s Next

CVE-2024-28757 is a reminder that ubiquitous open‑source components like libexpat can lurk in unexpected corners of your infrastructure. Microsoft’s advisory correctly points Azure Linux customers to a fix, but it also signals that the company’s vulnerability mapping is a work in progress. Expect broader CSAF/VEX coverage over the coming months, but don’t wait for it – actively inventory your Microsoft-supplied artifacts now.

As more vendors adopt machine‑readable security advisories, the days of “silence equals safety” are numbered. For now, treat every product that hasn’t been explicitly cleared as an open question, and verify it yourself. By scanning for libexpat across your Linux VMs, containers, and even Windows‑based development environments, you can close the gap before an attacker finds it.