CVE-2026-7210

What it actually does

This is a denial-of-service vulnerability in Python XML parsing paths that use Expat through `xml.parsers.expat` or `xml.etree.ElementTree`. The hash-flooding protection uses insufficient entropy, allowing a specially crafted XML document to create excessive hash collisions during parsing. When vulnerable code parses attacker-controlled XML, CPU time can be consumed disproportionately, slowing or blocking the affected Python process and reducing service availability. Full mitigation requires both an updated Expat library, version 2.8.0 or later, and the corresponding Python-side patch.

Why it matters to the business

Applications, APIs, data-processing jobs, or backend services that accept XML from untrusted sources may be slowed or made unavailable by a malicious XML payload. The primary consequence is operational disruption rather than data theft: request queues can back up, worker processes can be exhausted, and dependent services may experience timeouts. Although this issue is not currently in CISA KEV, has low EPSS, and has no known mature public exploit based on the provided data, it is network-reachable in common XML-processing workflows and should be prioritized for internet-facing or business-critical services.

How an attack unfolds

An attacker identifies an application endpoint, message queue consumer, file upload workflow, API integration, or background job that parses XML using Python’s `xml.parsers.expat` or `xml.etree.ElementTree`. The attacker submits a crafted XML document designed to cause hash collisions inside the parser. Because the parser’s hash-flooding protection does not use sufficient entropy, parsing the document becomes computationally expensive. Repeated submissions can consume CPU on application workers, increase request latency, trigger timeouts, and potentially make the service unavailable. The attack does not require authentication if the XML parsing path is exposed to unauthenticated users; in authenticated-only workflows, any user able to supply XML may be able to trigger the condition.

How to fix it

Upgrade affected Python runtimes and packages to versions that include the Python-side fix, and ensure the underlying Expat library is upgraded to libexpat 2.8.0 or later. Both pieces are required for full mitigation. Where Python is dynamically linked to system Expat, update the operating system package that provides Expat and restart Python services so they load the fixed library. Where Python embeds or vendors Expat, upgrade Python to a vendor release that includes the fix. If immediate patching is not possible, reduce exposure by rejecting untrusted XML where feasible, enforcing strict request size and parsing time limits, rate-limiting XML-submitting clients, isolating XML parsing in constrained worker processes, and applying upstream WAF/API gateway limits for XML-heavy endpoints. Avoid treating generic XML schema validation as a complete mitigation, because the resource exhaustion occurs during parsing behavior.

How to confirm the fix worked

Confirm the running Python build and linked Expat version. In Python, check `pyexpat.EXPAT_VERSION` and verify it reports Expat 2.8.0 or later after patching. Also verify that the Python distribution or vendor package includes the CVE-specific Python patch, not only a newer system library. For dynamically linked installations, use OS package inventory and dependency inspection tools such as `ldd`, package manager queries, or container image scanners to confirm which Expat library the Python interpreter loads. Restart all long-running Python services after updating. Validate exposure by inventorying code paths that import or use `xml.parsers.expat`, `xml.etree.ElementTree`, or libraries that rely on them, especially where XML is accepted from users, partners, web requests, uploads, email attachments, SAML-like integrations, SOAP services, or message queues. Confirm mitigations by testing rate limits, request body limits, worker timeouts, and parser isolation controls in a non-production environment.

Typical attack path

1. Find an application, API, upload feature, integration endpoint, or queue consumer that accepts XML input.
2. Confirm or infer that the service is implemented in Python and parses XML using Expat-backed libraries such as `xml.parsers.expat` or `xml.etree.ElementTree`.
3. Generate a crafted XML document intended to trigger hash collisions during parser processing.
4. Submit the document to the vulnerable parsing path.
5. Repeat or parallelize submissions to increase CPU consumption and tie up application workers.
6. Cause degraded performance, request timeouts, job backlog, or service unavailability.

How to detect it

This vulnerability generally produces availability and performance artifacts rather than durable compromise indicators. Review application, web server, API gateway, load balancer, container, host, and APM telemetry for periods of abnormal CPU saturation or latency correlated with XML submissions. Focus on endpoints that accept XML request bodies, XML file uploads, SOAP-style requests, XML-based integrations, or message queue payloads. Look for repeated large or unusual XML payloads from the same source, bursts of requests with `Content-Type` values such as `application/xml`, `text/xml`, or SOAP-related media types, elevated parser exceptions, request timeouts, worker process restarts, autoscaling events, and queue backlog growth. On hosts and containers, correlate high CPU in Python processes with inbound XML traffic. Since no named threat actors or known exploitation campaigns are provided, detection should rely on behavioral signals rather than actor-specific infrastructure. For forensic review, preserve representative XML payloads, access logs, application parsing errors, process metrics, and container or orchestration restart events around the suspected outage window.

What your security team should do

• Prioritize patching internet-facing, unauthenticated, or high-volume services that accept XML and run Python XML parsing code.
• Upgrade libexpat to 2.8.0 or later and deploy Python vendor updates that include the corresponding patch; verify both conditions are true.
• Inventory Python applications, containers, serverless functions, batch jobs, and third-party services that parse XML using `xml.parsers.expat`, `xml.etree.ElementTree`, or dependent libraries.
• Add or tighten request body limits, XML upload limits, parser timeouts, worker CPU limits, and rate limits for XML-processing endpoints.
• Restart long-running Python services after updating Python or Expat packages to ensure fixed libraries are loaded.
• Monitor for spikes in CPU usage, XML parse time, request latency, HTTP 408/429/500/502/503/504 responses, and worker restarts associated with XML-handling routes.
• Because this is not currently KEV-listed and has low EPSS, schedule broadly across the fleet, but escalate urgency for externally reachable or mission-critical XML workflows.