A runc container escape vulnerability tracked as CVE-2024-45310 has prompted an official advisory from Microsoft, but the company’s wording has left many administrators with more questions than answers. On its Security Response Center update guide, Microsoft affirmed that Azure Linux “includes this open‑source library and is therefore potentially affected,” while stopping short of declaring any other Microsoft product safe. For Azure Linux users, that means a clear call to action. For everyone else running Microsoft‑supplied infrastructure—AKS nodes, WSL2 instances, Marketplace appliances—it means doing your own homework.

What actually changed

On October 31, 2025, Microsoft updated its CVE‑2024‑45310 entry on the MSRC portal with a frequently‑asked‑questions section that directly addresses whether Azure Linux is the only affected product. The advisory confirms that Azure Linux ships with runc and is therefore vulnerable. It then adds: “If impact to additional products is identified, we will update the CVE to reflect this.” That promise is part of a broader transparency push Microsoft launched in October 2025, when it began publishing machine‑readable CSAF and VEX documents for open‑source components in its products, starting with Azure Linux.

The underlying bug, CVE‑2024‑45310, is a race condition in runc—the low‑level OCI runtime used by container engines like containerd and Docker—that can allow an attacker who can start containers with crafted volume configurations to create empty files or directories on the host filesystem. The flaw originates in runc’s use of os.MkdirAll to create volume directories; a race between two containers sharing a volume can trick runc into creating an empty file instead of a directory, which in certain configurations can be abused for privilege escalation or host compromise. Upstream, the flaw affects runc versions up to 1.1.13 and some 1.2.0‑rc2 releases; patches are available in runc 1.1.14 and later. The vulnerability carries a medium severity rating, but in multi‑tenant or CI/CD environments where untrusted containers run, even host file creation can be a stepping stone to further compromise.

Microsoft’s advisory does not assert that Azure Linux is the only product that bundles runc. It says only that Azure Linux is the product it has verified and attested to date. The company is conducting a phased inventory of its software artifacts, and as it checks each one for runc, it will update the CVE record with additional products if they are found affected.

What it means for you

For different roles, the urgency varies.

Home users and developers running WSL2: If you use WSL2 for development and pull container images from the internet without strict trust boundaries, you should verify the runc version inside your WSL instances. The default WSL kernel and userland may or may not include runc; the presence depends on the distribution you installed. For example, if you run Docker Desktop with the WSL2 backend, the Docker runtime inside WSL likely bundles its own runc binary. Run runc --version in your WSL terminal. If you find a vulnerable version, update your distro packages or replace runc manually by downloading a patched binary from the upstream project.

Azure Linux administrators: You have a clear signal. Microsoft says your system is potentially affected. Check your runc version immediately. If you are running an Azure Linux image that ships runc prior to 1.1.14, you must patch. Microsoft may provide official updated packages; apply them via your normal package manager when available. If no packages are out yet, you can rebuild runc from upstream or apply mitigations until patches arrive.

AKS and Azure VM operators: Kubernetes nodes in Azure Kubernetes Service and Azure VMs from the marketplace might include runc. AKS images often ship containerd, which includes runc. Check your node image versions. Run runc --version on a test node or inspect the image’s package list. If you find a vulnerable version, you have two options: upgrade the node image to one that includes a patched runc (check Microsoft’s AKS release notes), or manually replace the runc binary on existing nodes—but manual replacement can break node health and is not recommended for production without thorough testing.

Security and compliance teams: Your vulnerability scanners likely already flag CVE‑2024‑45310. But because Microsoft’s VEX statements are still being rolled out, you cannot rely solely on the absence of a VEX “affected” statement for products other than Azure Linux. You must inventory all Microsoft‑supplied artifacts in your environment and check them directly. Feed Microsoft’s CSAF/VEX data into your pipeline as it becomes available, but for now, manual or automated artifact inspection is required to close the verification gap.

How we got here

runc is the de facto runtime for containers on Linux, used under the hood by Docker, containerd, and CRI‑O. The vulnerability was discovered and reported through upstream channels, and patches were released in mid‑2024. Since then, Linux distributions and container platforms have been rolling out fixes. Microsoft, however, has a uniquely diverse portfolio: it ships its own Linux distribution (Azure Linux), provides managed Kubernetes, offers marketplace images, and even embeds Linux in Windows via WSL2. Each artifact may contain a different runc package or version.

In October 2025, Microsoft announced a new commitment to machine‑readable security advisories using the Common Security Advisory Framework (CSAF) and the Vulnerability Exploitability eXchange (VEX) standard. Starting with Azure Linux, the company began publishing VEX documents that explicitly state for each CVE whether a product is affected, not affected, or fixed. This replaces the old model where vendors would issue blanket statements of “product X is affected” without machine‑consumable data, forcing security teams to manually parse human‑readable bulletins. The move aligns with industry trends driven by executive orders and the need for automated supply chain security.

The CVE‑2024‑45310 entry is one of the first to include this new FAQ format. The question “Is Azure Linux the only Microsoft product…” was likely prompted by customers who noticed that only Azure Linux appeared in the advisory, even though they suspected other Microsoft offerings might contain runc. Microsoft’s response makes it clear: Azure Linux is not necessarily the only one, it’s just the only one Microsoft has looked at and attested to so far.

What to do now

  1. Inventory all Microsoft‑supplied artifacts in your environment. Go beyond Azure Linux. Make a list of every VM image, AKS node, WSL distribution, and marketplace appliance you run. For each, determine whether runc is present and, if so, its version. Use commands like:
    - runc --version
    - dpkg -l | grep runc (Debian/Ubuntu)
    - rpm -qa | grep runc (RHEL/CentOS/Fedora)
    - containerd --version (to check the bundled runc)
    - dockerd --version (Docker’s runtime)
    For images you haven’t deployed yet, pull them into a sandbox and inspect the package list with dpkg --list or rpm -qa.

  2. Patch where possible. If you find runc versions below 1.1.14, upgrade. On Azure Linux, wait for an official package update or apply the upstream patch manually. On AKS nodes, check for new node image versions; Microsoft often releases patched images. For other distributions, consult your vendor’s security advisories for exact package versions. The upstream fix is in runc 1.1.14; your distro may backport the fix to an earlier version number—verify with the distro’s changelog.

  3. When patching isn’t immediately possible, apply mitigations.
    - Enforce user namespaces and rootless containers to reduce the attack surface. Rootless mode limits what an attacker can write to the host even if they exploit the race.
    - Tighten LSM policies (SELinux or AppArmor) to restrict what runc can write on the host. This adds an extra layer of defense, though it’s not a guaranteed fix.
    - Restrict the ability of untrusted users to launch containers with arbitrary volume mounts, especially in shared CI/build environments.

  4. Automate vulnerability tracking. Ingest Microsoft’s CSAF/VEX feeds into your vulnerability management platform. Several enterprise tools (e.g., Dependency‑Track, OWASP tools) already support CSAF; if yours doesn’t, you can use open‑source tools like cvemap or grype with a custom feed. Monitor the MSRC update guide for changes to CVE‑2024‑45310. Subscribe to Azure Linux security notifications.

  5. Request explicit attestations if needed. If you rely heavily on a Microsoft artifact that isn’t yet listed in a VEX document, contact Microsoft support or your account team and ask for an SBOM (Software Bill of Materials) or a formal statement about runc inclusion. For critical systems, this can provide the clarity you need to make risk decisions.

Outlook

Microsoft’s phased VEX rollout is a net positive for transparency, but it also underscores a fundamental truth about modern software supply chains: no single attestation covers everything. As the company works through its inventory, more products will appear in advisories—some affected, some not. In the meantime, proactive administrators should treat every Microsoft‑supplied Linux artifact as potentially carrying runc until proven otherwise. Watch for updates to the CVE entry and for new VEX documents in Microsoft’s feed. The next few months will reveal whether other products like AKS images or WSL components were carrying vulnerable runc versions all along. Until then, verify, patch, and monitor.