Azure Linux Attestation and CVE-2025-4435 Tarfile Risk

Microsoft’s public attestation names the Azure Linux distribution as a product that “includes this open‑source library and is therefore potentially affected,” but that statement is a scope declaration of Microsoft’s inventory work to date — not proof that Azure Linux is the only Microsoft product that could contain the vulnerable tarfile implementation. Microsoft has said it will update the CVE mapping if more Microsoft products are found to ship the affected component; in the meantime, customers must treat the Azure Linux attestation as authoritative for that product only and perform artifact‑level verification for other Microsoft images, services, and agents they run.

---

Background / Overview​

CVE‑2025‑4435 is a high‑severity defect in CPython’s tarfile module where the documented behavior of TarFile.errorlevel = 0 — namely, that filtered members should be skipped during extraction — can be bypassed and those members are still extracted. This can result in sensitive or unexpected files being created on disk when code extracts untrusted archives using tarfile with filtering. The vulnerability was publicly recorded on June 3, 2025 and has been assigned a CVSS v3.1 base score of 7.5 (High). Multiple upstream trackers (OSV, Debian security tracker, Amazon Linux advisory) and the Python security announcement describe the same root cause and link to the upstream CPython issue and fixes. At a practical level the attack model is straightforward: an attacker who can supply a crafted tar archive to a process that extracts it using Python’s tarfile APIs (with a filter and errorlevel settings that the developer believes will prevent extraction of filtered entries) may cause files to be written that the maintainer expected would be skipped. In many environments that parsing happens automatically — CI systems, data pipelines, package extractors, model artifact fetchers — so the real risk is unintended file placement and integrity/information exposure rather than memory corruption or remote code execution. Independent trackers show distribution maintainers have already issued package updates for mainstream releases (for example, fixed package updates in Amazon Linux 2023 and multiple Debian/enterprise Linux advisories). The CPython repo issue and the related pull request(s) document the code changes that remedy the logic error in tarfile.

---

What Microsoft actually published — and how to read it​

Microsoft’s Security Response Center (MSRC) has adopted a machine‑readable CSAF/VEX attestation program and has begun publishing product‑level attestations starting with the Azure Linux distribution (the family sometimes referenced as CBL‑Mariner / Azure Linux images). For CVE‑2025‑4435 Microsoft’s attestation says Azure Linux “includes this open‑source library and is therefore potentially affected,” and Microsoft explicitly promises to update the CVE/VEX records if additional Microsoft products are identified as carriers of the affected library. That language is procedural: it documents what Microsoft has validated so far and the commitment to broaden the attestation scope as their inventories are completed. Two points are critical when parsing Microsoft’s words:

• Authoritative scope: The attestation is authoritative for the exact Microsoft product it names (Azure Linux). If you run Azure Linux images from Microsoft, you can use Microsoft’s VEX/CSAF output as a deterministic automation input for detection and remediation.
• Not an exclusion for everything else: The absence of attestations for other Microsoft products does not prove those products don’t include the vulnerable library. The attestation signals Microsoft’s current validated mapping; other product families remain subject to inventory and triage. Microsoft will expand the VEX output when its internal mapping finds additional artifacts that include the component.

Multiple independent analyses arriving at the same interpretation emphasize that Microsoft’s published Azure Linux mapping is a validated, product‑scoped disclosure rather than a universal guarantee. Treat it as a provable “yes” for Azure Linux — and as a “work in progress” for everything else.

---

Short answer to the user’s question​

• Is Azure Linux the only Microsoft product that includes the open‑source tarfile implementation and is therefore potentially affected?
  • No — not necessarily. Azure Linux is the only Microsoft product that Microsoft has publicly attested as including the vulnerable library for CVE‑2025‑4435 as of the attestation publication. That is the extent of Microsoft’s published inventory mapping for this CVE so far. However, other Microsoft products and published images could also contain the same vulnerable Python runtime or baked‑in binaries, depending on how those artifacts were built. Microsoft has committed to update the CVE record if further products are identified, but an absence of attestations is not proof of absence of the vulnerable code.

---

Why the attestation for Azure Linux does not prove exclusivity​

Several technical and operational facts explain why a product‑level attestation for one Microsoft artifact cannot be extrapolated to the entire company’s product portfolio:

1) Build‑time variability is decisive​

Whether a product includes a particular library depends entirely on the product’s build pipeline, package manifest, and image configuration. Different Microsoft images and services are assembled with different base images, language runtimes, and statically linked binaries. Simply updating the system package in one image family does not automatically change what is embedded in other images or baked‑in appliances.

2) Statically compiled / baked‑in binaries​

Python applications and third‑party tools can be distributed as prebuilt, statically packaged artifacts (e.g., standalone executables created with PyInstaller, zipapps with embedded interpreters, or container images with a specific Python wheel). Patching the distribution’s system Python package will not change embedded interpreters or precompiled artifacts; those must be rebuilt with patched Python releases to remove the vulnerability.

3) Multiple Microsoft distribution surfaces — independent inventories​

Microsoft publishes many distinct artifacts: Azure Linux images, Marketplace VM images, curated container images (for Azure Machine Learning and other services), AKS node images, WSL kernels and images, Windows agent installers, and managed service runtimes. Each is an independent inventory target and must be validated separately. Microsoft’s VEX rollout is phased and started with Azure Linux for practical reasons; expect the mapping to expand over time.

4) Third‑party and partner artifacts hosted by Microsoft​

Marketplace images, partner appliances, and third‑party container images hosted in Azure may ship older or different dependency stacks; Microsoft’s attestation for first‑party Azure Linux images does not automatically cover those third‑party artifacts. These “long tail” items are a common cause of delayed remediation in large estates.

---

How to verify whether a Microsoft product or image you run is affected​

There’s no shortcut: the only reliable answer is to inspect the actual artifact you run (image, VM, binary). Below is a prioritized, repeatable verification checklist for administrators and platform teams.

Inventory — find candidate artifacts​

• Enumerate all Microsoft‑published images in your estate: Azure Marketplace VMs, Azure Linux VM images, curated Azure ML images, AKS node images, Databricks runtimes, WSL2 images on developer hosts.
• Search container registries and private image caches for images that include Python runtimes or third‑party tools that may use Python’s tarfile.
• Identify on‑host binaries that unpack tar archives (CI runners, backup/restore scripts, ingestion pipelines).

Determine the runtime / package version​

• For running hosts or containers:
  • python -c "import sys; print(sys.version.replace('\n',' ')"
  • python -c "import tarfile, sys; print('tarfile from', tarfile.file if hasattr(tarfile, 'file') else 'built-in', sys.version)"
• For package‑managed Python:
  • Debian/Ubuntu: dpkg -l | grep python3; apt changelog python3.11 (or apt policy python3.11)
  • RHEL/Oracle: rpm -q python3 python3‑libs
• For container images (one‑time inspect):
  1. docker run --rm -it <image> python -c "import sys; print(sys.version)"
  2. docker run --rm <image> bash -lc 'python -c "import sys,tarfile; print(sys.version)"'

Check image SBOMs and VEX/CSAF outputs​

• Consume Microsoft’s published CSAF/VEX attestations for Azure Linux to automate detection for that product. For other Microsoft images or third‑party images, request SBOMs from the publisher or generate SBOMs from your local images and run a vulnerability scan.

If you find an affected runtime or binary​

1. Prioritize: Internet‑facing, multi‑tenant, or high‑privilege services first.
2. Patch or rebuild: upgrade the system/python package to the vendor’s fixed release, or rebuild any embedded interpreters or statically packaged artifacts with fixed CPython releases or apply the upstream patches. Many distro advisories list fixed package versions — follow those vendor advisories for the correct package releases for your OS.

---

Short‑term mitigations when patching/rebuilds are not immediately possible​

• Reject suspicious link targets before extracting: The public mitigation guidance for this tarfile family includes validating and rejecting tar members with unsafe linknames or parent‑directory segments before calling extract/extractall. A safe pre‑validation loop that rejects linknames containing “..” is an effective short‑term guard.
• Sandbox extraction: Run untrusted extraction in isolated sandboxes or containers with strict filesystem and privilege constraints; apply aggressive resource limits and mount namespaces to prevent cross‑host file placement.
• Block or queue untrusted archives: Avoid automatic extraction of archives from untrusted sources; process them through a staging pipeline that performs content inspection and sanitization first.
• Use image‑scanning and alerting: Add behavior monitoring to alert on unexpected file creation events in directories where archives are extracted.

---

Technical verification: patched versions and evidence​

Upstream tracking (OSV and CPython issue/PR activity) and distribution advisories list both the fix and the patched package releases. OSV collects the CPython commits and PRs that contain the fixes and shows the advisory metadata for CVE‑2025‑4435; Debian, Amazon Linux (ALAS), Oracle and enterprise Linux vendors have published package advisories and fixed package revisions for mainstream Python releases. The CPython issue that tracked multiple tarfile extraction problems (#135034) and the associated pull request(s) contain the specific code changes. Use vendor advisories to obtain the correct, OS‑specific package versions to install in your environment. Examples of vendor actions:

• Amazon Linux 2023 published fixes for python3.9/3.11/3.12 packages on June 23, 2025.
• Debian’s tracker lists fixed package versions for affected source packages.

If you rely on third‑party images from Microsoft (curated ML images, ACPT, Databricks runtime images, Marketplace appliances), check each image’s manifest or vendor advisory: these artifacts may be updated on a different cadence and require image replacement or rebuilds by the publisher. Microsoft’s VEX/CSAF output is authoritative for Azure Linux only unless Microsoft expands the mapping.

---

Practical remediation checklist (prioritized)​

1. Inventory: produce a list of images, VMs, containers and binaries that parse or extract tar archives. Automate this scan with container image scanners, SBOM ingestion, and package inventory tools.
2. Verify: for each candidate, determine the Python runtime version and whether the tarfile module in that runtime is at a fixed revision. Use vendor advisories / SBOMs to validate.
3. Patch or rebuild: apply vendor packages or rebuild artifacts with patched CPython releases (follow distro guidance). Replace or redeploy patched images.
4. Mitigate where immediate fixes are impossible: sandbox extraction, pre‑validate linknames, block untrusted automatic extraction.
5. Monitor and validate: add telemetry for unexpected file creation during extraction operations; put regression tests into CI to catch extraction‑behavior regressions.

---

Critical analysis — strengths and risks in Microsoft’s messaging and approach​

Notable strengths​

• Machine‑readable attestations (CSAF/VEX): Microsoft publishing VEX/CSAF for Azure Linux gives customers a deterministic automation signal for that specific product family. This reduces triage time and supports automated remediation workflows for affected Azure Linux images.
• Commitment to update: Microsoft’s explicit promise to expand the CVE/VEX mapping if additional products are discovered is operationally useful; it provides a clear place to monitor for changes.

Important caveats and risks​

• Attestation scope vs. ecosystem presence: The attestation documents what Microsoft validated, but it is not an exhaustive inventory of all Microsoft artifacts. Relying solely on Azure Linux being listed would create a blind spot for other Microsoft images, curated containers, or embedded binaries that might ship the vulnerable tarfile behavior. Organizations must perform their own artifact‑level verification.
• Long tail problem: Marketplace images, partner appliances, and long‑lived snapshots can lag in patches. These third‑party artifacts are often outside the immediate scope of first‑party attestation programs and require proactive scanning and vendor engagement.
• Rebuild requirement for embedded interpreters: Where Python interpreters are embedded or applications are statically packaged, mitigation requires rebuild/redeployment rather than a simple platform package update. That increases operational friction and time to remediation.

---

Final practical guidance for WindowsForum readers (straightforward actions)​

• Treat Microsoft’s Azure Linux attestation as an authoritative remediation signal for that product family — patch those images immediately according to Microsoft’s guidance.
• Do not assume other Microsoft images are clear just because they’re not listed; perform artifact‑level verification (SBOMs, container scans, in‑image Python runtime checks) across all Microsoft‑published images and services you consume.
• Prioritize internet‑facing and multi‑tenant workloads that unpack third‑party archives. Apply sandboxing, file‑validation, and image isolation as compensating controls while you rebuild or replace affected artifacts.
• Automate: ingest Microsoft’s VEX/CSAF outputs where available for Azure Linux, and augment with your own SBOM-based automation to mark and remediate images and binaries across your fleet.

---

Conclusion​

Microsoft’s message is precise: the company has confirmed Azure Linux includes the affected open‑source library and has published a machine‑readable attestation for that product; it will update the CVE mapping if additional Microsoft products are discovered to ship the vulnerable component. That makes Azure Linux the only Microsoft product publicly attested so far for CVE‑2025‑4435 — but it is not proof that no other Microsoft product can be affected. The correct operational stance is to treat Microsoft’s attestation as authoritative for Azure Linux while performing artifact‑level inspection of every Microsoft‑published image, container, and baked‑in binary you run. Follow vendor advisories to patch or rebuild, apply mitigations where immediate fixes are impractical, and automate detection so long‑tail images and partner artifacts are not left exposed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center