CVE-2026-6879

What it actually does

The flaw is an algorithmic complexity denial-of-service issue in Python XML processing. In affected Red Hat Python 3.10 through 3.14 packages, xml.etree.ElementTree Element.findall() and fully consumed Element.iterfind() can take O(n^2) time when evaluating XPath index predicates such as [1], [last()], or [last()-N] against XML documents containing many siblings with the same tag. Element.find() is affected in narrower cases where the selected match is near the end of a large sibling list, such as [last()] or [last()-N]. An attacker who can cause an application to parse attacker-influenced XML and evaluate these XPath forms can consume excessive CPU, slowing or stalling the worker process. The vulnerability affects availability, not confidentiality or integrity.

Why it matters to the business

Applications, APIs, background jobs, or integration services that parse untrusted or semi-trusted XML with Python ElementTree may become slow or unavailable when processing crafted XML inputs. The most likely operational impact is CPU exhaustion, request timeouts, queue backlogs, degraded service levels, and potential cascading failures if worker pools are saturated. The CVSS and EPSS indicate lower observed exploitation likelihood at this time, it is not listed in CISA KEV, and no public exploit maturity is reported, but exposure should still be addressed for internet-facing XML ingestion points and high-volume processing systems because denial-of-service flaws can be triggered repeatedly at low cost once an input path is identified.

How an attack unfolds

An attacker first identifies an application feature that accepts or retrieves XML, such as file upload, API submission, partner feed ingestion, SAML-like metadata handling, configuration import, or message processing. They then craft an XML document containing a large number of same-tag sibling elements. The attacker relies on the application using Element.findall(), fully consuming Element.iterfind(), or certain Element.find() calls with XPath index predicates such as [1], [last()], or [last()-N]. When the application evaluates the XPath expression, affected Python versions repeatedly scan sibling lists in a way that grows quadratically with the number of elements. By submitting one large document or many concurrent documents, the attacker can tie up CPU in the Python process, causing high latency, timeouts, failed jobs, and possible service unavailability. Successful exploitation generally requires a reachable XML input path plus application code that uses the affected XPath predicate patterns.

How to fix it

Upgrade affected Red Hat Python packages to the fixed versions from RHSA-2026:48278 or later: python3-10-main to 3.10.20-3.2.hum1, python3-11-main to 3.11.15-5.5.hum1, python3-12-main to 3.12.13-3.8.hum1, python3-13-main to 3.13.14-1.7.hum1, and python3-14-main to 3.14.6-2.2.hum1. Restart long-running Python services, workers, application servers, and containers after updating so the patched interpreter and libraries are loaded. Where immediate patching is not possible, mitigate by limiting XML request size, limiting maximum element count/depth, enforcing request and job execution timeouts, applying rate limits, rejecting unexpectedly large XML documents, and avoiding vulnerable XPath index predicate patterns against untrusted XML. Prefer streaming parsing or bounded iteration for large XML inputs where feasible.

How to confirm the fix worked

Confirm package versions using the operating system package manager and verify they are at or above the fixed Red Hat builds listed in RHSA-2026:48278. Confirm running services have been restarted after package updates by checking process start times or redeploying affected containers/images. Review application code for xml.etree.ElementTree usage of Element.findall(), Element.iterfind(), and Element.find() with XPath predicates such as [1], [last()], and [last()-N], especially on untrusted XML. Test representative XML ingestion paths with size and timeout controls enabled to verify large repeated-sibling XML documents are rejected, bounded, or processed within acceptable limits. Vulnerability scanners and software composition inventory should no longer report the affected Red Hat Python package versions after remediation.

Typical attack path

1. Find an application endpoint, job, or integration that processes XML supplied by users, partners, upstream systems, or remote URLs.
2. Create an XML payload with many repeated sibling elements using the same tag name.
3. Trigger code paths that call Element.findall(), fully consume Element.iterfind(), or call Element.find() with XPath index predicates such as [last()] or [last()-N].
4. Submit the payload once or repeatedly, potentially in parallel, to increase CPU consumption.
5. Cause application workers to spend excessive time evaluating XPath predicates, leading to request timeouts, queue buildup, degraded performance, or denial of service.

How to detect it

Look for signs of denial-of-service rather than data theft. Relevant sources include web access logs, API gateway logs, WAF logs, application logs, worker/job logs, container metrics, host CPU telemetry, APM traces, and error monitoring. Focus on requests or jobs that processed XML shortly before CPU saturation, request latency spikes, HTTP 408/429/499/500/502/503/504 responses, worker timeouts, queue backlog growth, or process restarts. Investigate unusually large XML payloads, XML documents with many repeated same-tag sibling elements, and repeated submissions from the same source. In code-aware telemetry or exception logs, look for slow calls involving xml.etree.ElementTree, Element.findall, Element.iterfind, Element.find, and XPath predicates containing [1], [last()], or [last()-N]. Because exploitation may leave no durable file artifact, correlate high CPU in Python processes with XML-processing endpoints and payload characteristics. No known named threat actors, ransomware campaigns, or CISA KEV exploitation are associated with this issue in the provided data.

• xml.etree.ElementTree
• Element.findall
• Element.iterfind
• Element.find
• [last()]
• [last()-
• [1]
• XPath predicate
• request timed out
• worker timeout
• CPU time limit exceeded
• HTTP 503
• HTTP 504
• application/xml
• text/xml

What your security team should do

• Inventory services, containers, batch jobs, and integrations using Red Hat Python 3.10, 3.11, 3.12, 3.13, or 3.14 that parse XML.
• Prioritize patching internet-facing XML ingestion paths, partner-feed processors, message queues, and high-volume background workers before purely internal low-volume tooling.
• Upgrade to the fixed RHSA-2026:48278 package versions and restart or redeploy all long-running Python processes.
• Search source code for Element.findall(), Element.iterfind(), Element.find(), and XPath predicates [1], [last()], or [last()-N] used with untrusted XML.
• Add defensive XML limits: maximum request body size, maximum XML file size, maximum sibling/element counts, parser/job timeouts, concurrency controls, and rate limiting.
• Monitor for CPU spikes, long XML parsing times, repeated request timeouts, and bursts of large XML submissions after publication, especially because the issue is newly disclosed.
• Create detection rules for unusually large XML payloads with repeated same-tag siblings followed by service latency, worker exhaustion, or timeout errors.