A Time‑of‑check / Time‑of‑use (TOCTOU) race condition in Podman — tracked as CVE‑2023‑0778 — allows a low‑privilege user to replace a regular file in a container volume with a symlink during an export operation, potentially causing Podman to follow that symlink and expose arbitrary host files to the export destination; the defect was fixed upstream in Podman v4.4.2, and Microsoft’s current public attestation names Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” while promising further CSAF/VEX‑based transparency as additional product inventories are completed.
Podman is a widely used daemonless container engine that supports rootless containers and a Docker‑compatible CLI. During certain file operations — notably when exporting a volume — Podman historically performed a check to confirm that an entry in the volume was a regular file and later performed a copy operation; between those two operations a malicious actor with write access to the volume could swap the file for a symlink pointing elsewhere on the host. That race (TOCTOU) is the heart of CVE‑2023‑0778 and results in possible exposure of host filesystem data to the exported archive.
The vulnerability was assessed as medium severity with a CVSS v3.1 base score of 6.8 in public vulnerability databases and vendor advisories. Multiple vendor advisories and vulnerability databases document the issue, the affected component (github.com/containers/podman/v4), and the upstream fix, which product maintainers have incorporated into distribution packages and container tooling over time.
Microsoft’s public messaging — visible in its vulnerability update guidance and transparency blog posts — has a specific phrasing for cases like this: they attest that Azure Linux (the Microsoft‑maintained Linux distribution) is a confirmed shipper of the implicated open‑source component and is therefore potentially affected. Microsoft also states it is publishing machine‑readable CSAF and VEX attestations (beginning in October 2025) and will update CVE mappings if further Microsoft products are discovered to include the vulnerable component. That phrasing is important — it is a product‑scoped attestation, not an exhaustive statement about every Microsoft image or artifact.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
Podman is a widely used daemonless container engine that supports rootless containers and a Docker‑compatible CLI. During certain file operations — notably when exporting a volume — Podman historically performed a check to confirm that an entry in the volume was a regular file and later performed a copy operation; between those two operations a malicious actor with write access to the volume could swap the file for a symlink pointing elsewhere on the host. That race (TOCTOU) is the heart of CVE‑2023‑0778 and results in possible exposure of host filesystem data to the exported archive.The vulnerability was assessed as medium severity with a CVSS v3.1 base score of 6.8 in public vulnerability databases and vendor advisories. Multiple vendor advisories and vulnerability databases document the issue, the affected component (github.com/containers/podman/v4), and the upstream fix, which product maintainers have incorporated into distribution packages and container tooling over time.
Microsoft’s public messaging — visible in its vulnerability update guidance and transparency blog posts — has a specific phrasing for cases like this: they attest that Azure Linux (the Microsoft‑maintained Linux distribution) is a confirmed shipper of the implicated open‑source component and is therefore potentially affected. Microsoft also states it is publishing machine‑readable CSAF and VEX attestations (beginning in October 2025) and will update CVE mappings if further Microsoft products are discovered to include the vulnerable component. That phrasing is important — it is a product‑scoped attestation, not an exhaustive statement about every Microsoft image or artifact.
Technical breakdown: how CVE‑2023‑0778 works
The TOCTOU vector, step by step
- Podman initiates an export of a container volume or other file tree and encounters an entry it intends to copy.
- Podman checks metadata (time‑of‑check) to ensure the entry is a regular file (not a symlink or device).
- Before Podman performs the copy (time‑of‑use), an attacker with write access to the volume replaces the file with a symlink that points to an arbitrary path on the host.
- When Podman performs the copy, it follows the symlink and copies the target file into the exported archive, thereby granting read access to that host file where it should not.
Why this is more than an academic bug
TOCTOU bugs exploit race windows; they are harder to reproduce reliably, but in multi‑tenant systems or developer workflows where untrusted users share volumes (or developers run containers with volumes pointing into host directories) the conditions for exploitation can be present. The impact is confidentiality and integrity for files: sensitive host files may be exfiltrated, or unauthorized files could be injected into exported artifacts. Vendor advisories characterize the confidentiality impact as high for the specific paths attacked, even though exploitation complexity is nontrivial.The upstream fix and affected versions
Upstream Podman maintainers fixed the issue in the 4.4.2 release of the github.com/containers/podman/v4 module (and corresponding downstream packages). The fix centers on eliminating the vulnerable check‑then‑use pattern in the tar/volume export codepath (CreateTarFromSrc and related helpers), adding safer checks or atomic operations to prevent a swap‑in of a symlink during the operation. Distribution packages and container tooling maintainers reference the upstream commit and associated pull requests in their advisories.What Microsoft actually said (and what that wording means)
Microsoft’s attestation model: CSAF and VEX
Microsoft has publicly described a phased approach to using machine‑readable advisories (CSAF) and Vulnerability Exploitability eXchange documents (VEX) to declare whether a given Microsoft product includes a vulnerable upstream component and whether that product is affected, under investigation, fixed, or not affected. Microsoft started publishing CSAF for CVEs and began publishing VEX attestations in October 2025, initially focusing on Azure Linux and planning to expand their coverage over time.“Azure Linux includes this open‑source library and is therefore potentially affected” — unpacked
That sentence is intentionally narrow:- It confirms Azure Linux is a confirmed shipper of the implicated open‑source library (Podman code in this case).
- It means Microsoft has completed inventory for that product family and found the component there.
- It does not assert that other Microsoft products definitely do not include the component; rather, Microsoft will extend VEX attestations if it discovers additional products ship it. In other words, Azure Linux is an authoritative “known included” result; other Microsoft artifacts are unattested until Microsoft inventories them and publishes a VEX. Treat the explicit attestation as a positive hit for Azure Linux and absence of attestation for other products as “no public attestation yet,” not as proof of absence.
Is Azure Linux the only Microsoft product that includes the Podman library?
Short answer (practical)
No — not necessarily. Azure Linux is the only Microsoft product that Microsoft has publicly attested to include the implicated Podman library at the time of the advisory. Microsoft has stated it will update CVE mappings and publish VEX attestations if additional Microsoft products are found to include the same upstream component. However, the absence of a public attestation for a product is not proof that the product does not include the component; it may simply mean Microsoft has not completed a full inventory and attestation for that product yet.Why a conservative reading matters
Microsoft’s public language is procedural and phased by design: starting with Azure Linux allows Microsoft to validate and publish a canonical mapping for at least one product quickly. Large vendors with thousands of build artifacts and images need time to map third‑party components across distributions, kernel builds, Marketplace images, WSL kernel artifacts, container images they publish, and other product SKUs. Until that mapping is complete, operators must not assume other Microsoft images are unaffected. Independent verification is required for production inventories. Community reporting and distribution advisories (Red Hat, Ubuntu, Oracle Linux, etc.) show that Podman is included widely across enterprise Linux distributions, so the possibility that Microsoft‑distributed images or kernels elsewhere include the same upstream component is real.Practical implications for admins and security teams
Who should care
- Teams running Azure Linux images (confirmed potential hit).
- Any team running container hosts, developer workstations, CI runners, or cloud images that could include Podman packages — especially multi‑tenant hosts that accept build inputs from untrusted users.
- Operators of WSL distributions, Marketplace images, or Azure Marketplace Marketplace appliances that embed container tooling or Linux distributions.
- Security teams relying on inventory automation that ingests vendor VEX/CSAF files.
Immediate steps to triage and mitigate
- Inventory: Build a prioritized list of all images, kernels, and VM templates in your estate where Podman might be installed.
- Query package lists in images (rpm -qa | grep podman or dpkg -l | grep podman).
- Inspect container tools and developer workstation images.
- Check WSL distributions and their installed packages.
- Patch where possible: Upgrade Podman to version 4.4.2 or later in any affected package repositories or image build pipelines. Upstream advisories and OSV entries mark 4.4.2 as the fix.
- Avoid risky exports: Where patching is not immediately feasible, avoid running podman export or similar operations against volumes that may be writable by untrusted users or contain sensitive host mountpoints.
- Apply confinement: Use SELinux/AppArmor and appropriate container runtime isolation to reduce the ability of unprivileged container occupants to manipulate host filesystems or volumes. Distribution advisories emphasize using established confinement mechanisms as compensating controls.
- Harden workflows: Reduce volume sharing with untrusted workloads, and prefer bind mounts with stricter permissions or read‑only mounts where possible.
- Monitor and alert: Add detection rules for unusual tar/export operations or processes performing archive operations from container runtime contexts, and monitor for unexpected symlink resolution during exports.
How to check Microsoft’s attestations and your Microsoft assets
- Consume Microsoft’s CSAF/VEX feed (MSRC) for product‑scoped attestations; the feed is designed to be machine‑readable and to state whether Microsoft has marked a product as “Known affected,” “Not affected,” “Under investigation,” or “Fixed.” Microsoft began publishing these artifacts in October 2025 for Azure Linux and plans to expand coverage.
- For Azure images: inspect the installed package manifest of any Azure Marketplace or custom images you run in production.
- For WSL: check which WSL distributions are in use and query the package lists of each distribution.
- For Azure Kubernetes Service (AKS) and container hosts: check the node images and any bootstrap scripts that may install Podman or associated container toolchains.
- Where possible, prefer patched, vendor‑supported base images for deployments.
Critical analysis: strengths, gaps, and risk assessment
Notable strengths in Microsoft’s approach
- Transparency push: Microsoft’s move to publish CSAF and VEX attestations is a meaningful improvement for enterprises that rely on machine‑readable vulnerability metadata. This enables automation and reduces noisy false positives when a vendor can definitively say a product does or does not ship a particular upstream component.
- Product‑scoped accuracy: Attesting at product level (e.g., Azure Linux) gives actionable clarity to operators of that product — they know to prioritize those images immediately.
Existing and residual risks
- Coverage lag: A phased rollout means there is a window during which many Microsoft products lack explicit attestations. Operators who assume the absence of an attestation equals the absence of a vulnerability risk exposure.
- Artifact sprawl: Microsoft’s product ecosystem includes many image sources (WSL kernels, Marketplace images, Azure VM images, container images); comprehensive inventory is nontrivial and will take time.
- Dependency mapping complexity: Open‑source components like Podman are packaged and repackaged into many artifacts. A vulnerability in an upstream module may appear in unexpected places (build scripts, custom VM images, CI artifacts), meaning detection requires artifact‑level inspection beyond vendor attestations.
- Operational burden on customers: The promising automation benefits from VEX/CSAF will only be realized when Microsoft’s attestation coverage expands and when customers build the ingestion and correlation pipelines to use them effectively.
How serious is CVE‑2023‑0778 in the real world?
The vulnerability is moderate by standard scoring and has limited automation potential due to the need for a timing/race window and writable access to volumes; however, that same complexity does not eliminate practical risk. Multi‑tenant build hosts, continuous integration runners, or developer machines that accept untrusted input and mount volumes are realistic attack surfaces. Distribution and vendor advisories from Red Hat, Ubuntu, Oracle Linux and others show the issue received broad attention and was treated as a meaningful operational risk in enterprise Linux distributions.Recommended checklist for operations and security teams
- Confirm the presence of Podman and its version in:
- Azure Linux images you run (this is a confirmed product‑map).
- WSL distributions and WSL kernel builds you control.
- Any custom Marketplace images and VM templates.
- CI images and developer workstation images.
- If Podman < 4.4.2 is installed anywhere:
- Schedule an upgrade to Podman >= 4.4.2 as soon as practicable.
- If immediate upgrade is impossible, implement the compensating controls listed earlier (avoid exports, tighten permissions).
- Automate CSAF/VEX ingestion:
- Ingest Microsoft’s CSAF/VEX feed and combine it with your package‑level inventory to automatically flag Microsoft products certified as “Known affected.”
- Where Microsoft hasn’t provided attestations, treat Microsoft absence as “unverified” and default to artifact‑level checks.
- Educate dev teams:
- Remind developers not to share writable host paths into multi‑tenant containers.
- Add CI checks to disallow exports of images or volumes containing sensitive host paths.
- Logging and detection:
- Instrument exports and tar operations initiated by container runtimes.
- Alert on anomalous archive creations that include unexpected absolute paths or references outside the intended export root.
When vendor attestation isn’t enough: deeper verification techniques
- Package queries inside images: run rpm or dpkg queries against image layers to find packaged podman versions.
- Inspect compiled binaries: for Go modules, tools like svscan/OSV or binary scanners can detect linked module versions or code snippets.
- Rebuild provenance: where images are produced by automated pipelines, confirm the pipeline’s base image and package install steps that could introduce Podman into the artifact.
- Use ephemeral verification: spin a temporary instance of the image, list installed packages, and run controlled export tests in a sandbox to validate behaviour (do not do this on production hosts).
Conclusion
CVE‑2023‑0778 is a real TOCTOU weakness in Podman that was fixed upstream in Podman v4.4.2; distribution and vendor advisories classify it as a medium severity issue with a meaningful confidentiality impact under plausible attack scenarios. Microsoft’s public advisory correctly identifies Azure Linux as a product that includes the implicated open‑source library and is therefore potentially affected, and Microsoft’s recent commitment to publish CSAF/VEX attestations (started October 2025) is a positive step toward machine‑readable, product‑level clarity. However, Azure Linux being attested does not guarantee it is the only Microsoft product that could include the vulnerable component — absence of attestation is not proof of absence of the component. Security teams must therefore combine vendor VEX/CSAF signals with their own artifact‑level inventories and immediate patching and hardening actions (upgrade to Podman ≥ 4.4.2, reduce risky exports, tighten volume and permission models) to reduce exposure quickly and reliably.Source: MSRC Security Update Guide - Microsoft Security Response Center
