This advisory explains CVE-2025-6075 (quadratic complexity in os.path.expandvars, what Microsoft’s MSRC statement means when it calls out Azure Linux, and practical steps for defenders to verify and remediate exposure across Microsoft products and services.
Executive summary — short answer
- Microsoft’s public statement identifies the Azure Linux distribution (the Azure Linux images Microsoft builds/publishes) as the Microsoft product that it has mapped to this open‑source component and therefore the one Microsoft is tracking as “potentially affected” right now.
- That statement is an attestation of current scope, not a technical guarantee that no other Microsoft product could ever include the same CPython component. Customers should not assume other Microsoft SKUs are unaffected — they should verify their own images and managed services.
- CVE-2025-6075 is a performance / algorithmic vulnerability in Python’s os.path.expandvars: certain user-controlled inputs can cause the expansion routine to perform with quadratic time complexity, which can be abused to cause high CPU consumption or degrade service (a denial‑of‑service style effect). The flaw does not enable arbitrary code execution or data exfiltration by itself — the impact is resource exhaustion/performance degradation when untrusted input is fed to expandvars.
- The upstream Python (CPython) project identified the problem and has published fixes (commits cherry‑picked to stable branches and main). The upstream change replaces the older repeated‑scan approach with a more efficient pattern-based implementation to avoid quadratic blowup. Administrators should update Python to a patched release or apply vendor-supplied patches.
- The CPython project and public vulnerability trackers list CPython builds prior to the fixed releases as affected (downstream vendors and distributions may have varying vulnerability windows depending on backports). Check your installed Python package versions against your distro/vendor advisories; many Linux distributions have already issued package-level advisories and patches.
- Microsoft’s MSRC messaging around this CVE (and other third‑party CVEs) uses machine‑readable CSAF/VEX attestations to say which Microsoft product builds include a given upstream component. In its published rollout for VEX, Microsoft explained it started with Azure Linux and will expand attestations to other product families over time. That is the context for Microsoft’s wording that “Azure Linux is the product that includes the open-source library and is therefore potentially affected” and the pledge that “If impact to additional products is identified, we will update the CVE to reflect this.”
- Practically, that means: at the time Microsoft published its mapping, Azure Linux was the only Microsoft product it had validated and attested as carrying the specific upstream component. It’s not a statement that no other Microsoft product could ever include CPython or the same vulnerable code; it’s a statement of the vendor’s validated,published scope at that time.
- Microsoft adopted a phased approach to publishing VEX/CSAF attestations and started with Azure Linux (a single well-defined product family) to validate processes and automation before wider roll‑out. That is intentional: VEX attestation is a mapping from component -> product build, and it’s normal for vendors to start with a single product family and expand. The MSRC blog explains that rollout and why starting with one product reduces noise and increases accuracy.
No. Two separate but related facts matter for your environment:
1) Is there an instance of vulnerable CPython (or a distribution package that contains the vulnerable code) running in your environment? If yes, you are potentially exposed regardless of vendor attestations. Public attestations speed triage but do not replace inventory. 2) Does that vulnerable usage actually pass untrusted input into os.path.expandvars? If the code does not call expandvars on attacker-controlled input, the practical risk is lower. But many applications and scripts do expand environment-like templates; verify call paths and input sources. How to determine if you (or your Microsoft-hosted workloads) are affected — practical checklist
- Inventory Python runtimes and packages:
- On Linux servers: python3 --version and check the packaged python3 version (dpkg -l python3 or rpm -q python3). Verify against vendor advisories.
- In containers: inspect the base image (e.g., FROM line) and run python --version inside the container.
- In Azure managed images or curated environments (Azure ML, Azure Container images, Azure Functions): check the image manifest, image tags, or Microsoft curated image documentation to see which Python / runtime versions are included. Microsoft’s VEX/CSAF feed for Azure Linux can be used to confirm attested Azure Linux images.
- Search your codebase for uses of os.path.expandvars:
- Grep / static analysis: grep -R "expandvars(" path/to/code or use code search tools. Audit callers and check whether the input is derived from user-controlled sources (API parameters, uploaded templates, web form fields).
- Monitor for signs of exploitation:
- Sudden CPU spikes on Python processes that call back into code that may use expandvars.
- Repeated long-running expandvars calls in logs / traces; instrument with tracing or profiling in critical services.
- For Microsoft products: consult the Microsoft VEX/CSAF attestation for Azure Linux for product-scoped status and check MSRC product notifications for updates. Microsoft has indicated it will expand attestations if more products are discovered to include the component.
- Apply input validation: disallow or sanitize untrusted templates passed to expandvars; treat user data as data, not templates. For example, restrict the allowed variable syntax or length of the template string before calling expandvars.
- Rate-limit/CPU quotas: run untrusted processing in constrained containers or processes with CPU quotas (cgroups / container limits) so an abuse attempt cannot starve other services.
- Use timeouts: if you call Python code from a service, consider executing risky operations in subprocesses with wall‑clock timeouts to avoid long‑running CPU loops.
- Replace expandvars when needed: if you must process user-controlled templates, implement a safer, linear-time expansion routine (or use a library that guarantees linear complexity) and carefully limit template features.
- For managed Azure customers: follow the Azure Linux patch guidance from Microsoft and apply the vendor-provided updates when available (MSRC / VEX will show product mapping and patch status).
- Upgrade Python / apply vendor patches:
- Use your OS/package vendor’s patched Python packages. Many distributions have already published fixes or backported patches to stable branches — check your distro security tracker and apply updates.
- If you build CPython from source, update to the commit range that includes the fix (upstream commit f029e8db… and subsequent cherry‑picks to stable branches) or upgrade to a release that contains the patch.
- For Azure Linux customers: apply Microsoft’s published Azure Linux updates as they are released and follow the associated VEX/CSAF attestations for status. Microsoft will list which Azure Linux images contain the fix.
- For other Microsoft-hosted pieces (Azure Functions, Azure ML curated images, Marketplace images): ask image owners/operators to confirm whether their particular image includes the vulnerable CPython and when an updated image will be published; do not assume that because Microsoft has attested Azure Linux only, other Microsoft images are automatically safe. Microsoft has committed to expanding VEX/CSAF coverage, but you must verify specific images/offerings you use.
- Check system Python version:
- python3 --version
- dpkg -l | grep python3 (Debian/Ubuntu)
- rpm -q python3 (RHEL/CentOS/SUSE)
- Search for expandvars in your code:
- grep -R --line-number "expandvars(" /srv /app /opt || true
- Container inspection:
- docker run --rm -it <image> python3 -V
- docker history --no-trunc <image> | head -n 20
- Host-level detection of abnormal CPU usage:
- top or htop and ps -eo pid,cmd,%cpu --sort=-%cpu | head
- Microsoft’s current public posture (the VEX/CSAF rollout) is to publish the attested product mapping for Azure Linux and expand coverage over time. If Microsoft finds this CPython component in additional Microsoft products, MSRC will update the VEX/CSAF data and the CVE/product mapping accordingly. Customers should monitor MSRC advisories and the VEX feed for changes.
- Inventory: find Python runtimes and container images in your environment and identify where expandvars could be called on untrusted input.
- Patch where possible: apply vendor/distro Python updates or replace vulnerable images with updated ones. Prioritize internet-facing and high‑throughput services that process user-supplied templates.
- Mitigate: implement input validation, CPU/timeout limits, and temporary code changes to avoid calling expandvars on untrusted strings.
- Monitor: add CPU and latency alerts for Python services and instrument calls that might invoke expandvars.
- Track vendor attestations: if you run Azure Linux images, use Microsoft’s VEX/CSAF attestation to confirm whether the particular image/build you run has been marked as affected/fixed. For other Microsoft-hosted images and services, request image manifests and patch timelines from the product owner.
- Vendor VEX/CSAF attestations (like Microsoft’s for Azure Linux) significantly speed and clarify triage for customers — but they are only as complete as the vendor’s build mappings at the time of publication. Treat Microsoft’s statement that “Azure Linux is the product identified so far” as accurate for the vendor’s validated scope, but perform host- and image-level verification in your environment as the authoritative check for exposure. Microsoft has publicly committed to updating the record if they identify more Microsoft products that ship the same open-source component.
- Produce a short script to scan a Linux host or container registry for installed Python versions and grep for expandvars uses in deployed code; or
- Fetch and summarize the Microsoft VEX/CSAF attestation file for Azure Linux (and show how to query it programmatically) so you can map image IDs to attestation status.
- OSV / public vulnerability record for CVE‑2025‑6075 (summary and affected CPython versions).
- CVE trackers / aggregate pages listing the vulnerability and affected product markers.
- Python upstream commits / check‑ins fixing the quadratic complexity in os.path.expandvars (commit f029e8d and cherry‑picks into stable branches).
- Microsoft MSRC blog on the VEX/CSAF rollout (October 2025) explaining Azure Linux attestation and the phased approach to publishing VEX.
- Microsoft public messaging / forum analyses explaining the operational meaning of “Azure Linux is the product Microsoft has identified so far” and why customers should still verify their specific images/environments.
Source: MSRC Security Update Guide - Microsoft Security Response Center
