CVE-2026-6879: CPython XML Index Queries Can Exhaust CPU

The vulnerable component is

, the limited XPath-style selector engine used behind

,

, and

. Microsoft’s advisory labels the flaw “Quadratic Behavior in xml.etree.ElementPath Index Predicates,” while CPython’s changelog ties the security fix to GitHub issue 152674 and pull request 152676. The changelog identifies the affected query forms as positional predicates such as

,

, and

when an XML document has many siblings with the same tag name.

The important limitation is also the most easily missed one: parsing a malicious XML file alone is not the full trigger. A program must subsequently run one of those ElementTree path queries against the parsed tree. That makes CVE-2026-6879 a risk for services that accept XML from users, partners, devices, or queues and then perform predictable positional lookups over it—especially where the lookup path is baked into application code and developers assume the XML has already been safely parsed.

The flaw sits after XML parsing, in a common lookup pattern​

Python’s standard

module supports a deliberately constrained path syntax. It is not a full XPath implementation, but it does support searching descendants and filtering a tag selection by position. A selector such as

means “find the first

among matching siblings”;

selects the last;

selects the one before it.

Those predicates sound innocuous because they return only one node per parent. The expensive part is determining which sibling each candidate is. On a tree with a very large run of same-named elements, a naïve implementation can repeatedly reconstruct or rescan the sibling list to calculate each candidate’s position. The total work then grows with the square of the sibling count rather than roughly in proportion to it.

That growth curve changes the operational problem. Doubling a normal linear workload roughly doubles its processing time; doubling a quadratic workload can require about four times the work. An attacker does not need malformed XML, code execution, or a parser crash. They need an application that accepts an oversized but valid XML structure and applies a vulnerable positional ElementPath query before it enforces useful document-size, node-count, or CPU limits.

CPython’s public documentation confirms that these position predicates are ordinary supported ElementTree syntax. The CPython changelog confirms that

,

, and

were changed to avoid the quadratic behavior for those predicates on documents with many same-tag siblings. In other words, the fix addresses query evaluation, not XML well-formedness and not external entity processing.

The public advisory is ahead of the release guidance​

The MSRC record was published on August 8, 2026, but its public-facing presentation does not yet supply the information administrators normally need for deployment triage: a CVSS vector, a fixed-version list, a KB number, a Microsoft product/build mapping, or a download path. The record’s assigning CNA is Microsoft, which may lead Windows shops to look for a monthly cumulative update. They should not wait for one without verifying the Python distribution actually in use.

CPython’s own development changelog lists the ElementPath change under its Security section for “Python next,” and the project’s source history shows the corrective commit landing recently. That establishes that a fix exists upstream. It does not establish that every supported stable CPython branch has received the patch, nor that currently installed Windows distributions—whether sourced from python.org, the Microsoft Store, Visual Studio tooling, Conda, embedded product runtimes, or application virtual environments—already contain it.

That distinction is the main practical finding from the available record. Microsoft’s CVE publication identifies a real upstream flaw, but it has not yet delivered the downstream compatibility matrix needed to convert the CVE into a simple “install version X” instruction. No independent security outlet had published a tested affected-release matrix or evidence of exploitation at the time of review.

For asset owners, “Python installed” is also too broad a detection criterion. The risk is more specific:

• A Windows machine is in scope when it runs an application using CPython’s standard-library xml.etree.ElementTree implementation.
• The application must process XML whose structure can be influenced by an untrusted party, directly or indirectly.
• The application must call find(), findall(), or iterfind() with a path containing an index predicate such as [1], [last()], or [last()-N].
• XML that contains a very large number of same-tag siblings raises the likelihood of disruptive CPU use.

A workstation with Python installed for local scripting but no untrusted XML processing is not equivalent to an internet-facing XML API, a device-management platform importing vendor feeds, or a document-processing service running as a Windows service account.

Why ordinary XML defenses may not catch it​

Security teams have learned to treat XML as a special input class because of external entities, expansion attacks, oversized payloads, deeply nested structures, and namespace complexity. CVE-2026-6879 belongs in that broader family of resource-exhaustion failures, but it is not solved simply by disabling DTDs or external entity resolution.

The XML can be syntactically valid, contain no external references, and have shallow nesting. The problematic shape is breadth: a parent element with many children carrying the same tag. A service might successfully parse the document, pass existing XML security checks, then burn CPU during a later business-logic step that asks for the first or last matching element.

This means application-level resource controls are relevant even after an upstream patch becomes available. Reverse proxies and IIS request-size limits help only when they are configured tightly enough to constrain the input. A small document can still contain a high count of compact XML elements, and a large but legitimate document may enter through a file share, message broker, local synchronization agent, or line-of-business integration rather than an HTTP endpoint.

For services where XML is necessary, teams should review maximum payload size, maximum element count where their parser or ingestion layer supports it, per-request timeouts, worker-process CPU limits, and queue isolation. A single request that ties up a Python worker is a nuisance; the same request repeated across every worker can become an availability incident.

What Windows and Python administrators should do now​

The immediate task is inventory and exposure review, not indiscriminate removal of Python. Identify the actual interpreter each service uses, because

in an administrator’s shell often says nothing about the interpreter embedded in a product, virtual environment, scheduled task, or Windows service.

For internally maintained code, search for calls to

,

, and

on ElementTree elements, then inspect the path strings for positional predicates. The expressions most clearly implicated by CPython’s security changelog are forms like

,

, and

. Treat fixed query strings as potentially reachable if they run against externally supplied XML; the attacker controls the tree shape even when they do not control the query text.

Where the query is not necessary, avoid positional ElementPath selection on untrusted documents. In some cases, iterating children once in application code and retaining the first or last matching node provides predictable linear behavior and makes input-size checks explicit. That is a mitigation, not a substitute for tracking the upstream fix.

For third-party Windows software, ask the vendor three direct questions: which CPython version is embedded, whether it uses

on untrusted XML, and when it will ship the CPython fix for CVE-2026-6879. Vendors that only answer that Windows is fully patched have not answered the relevant question.

The patch will matter more than the CVE label​

CVE-2026-6879 is a straightforward resource-exhaustion defect, but its publication exposes a familiar Windows fleet-management gap: a CVE can carry Microsoft’s name while the remediation path belongs to a separately distributed language runtime. The patch is now documented upstream for CPython’s forthcoming code line; the outstanding work is getting fixed builds into maintained Python releases and into the many Windows products that bundle their own interpreter.

Until version-specific guidance arrives, organizations should treat large untrusted XML plus ElementTree index predicates as the relevant exposure condition, put CPU and input limits around XML-processing services, and avoid assuming a fully updated Windows installation has already fixed the application runtime inside it.

References​

1. Primary source: MSRC
   Published: August 8, 2026 at 8:41 AM UTC
   
   Loading…

   msrc.microsoft.com
2. Related coverage: msrc.microsoft.com
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: docs.python.org
   
   Loading…

   docs.python.org
4. Related coverage: nvd.nist.gov
   
   

   Vulnerability APIs

   nvd.nist.gov
5. Related coverage: nvd.nist.gov
   
   Loading…

   nvd.nist.gov
6. Related coverage: cve.org
   
   Using Vulnogram with CVE Services

   PDF document

   www.cve.org
7. Related coverage: cve.org
   
   Loading…

   www.cve.org