A medium-severity vulnerability has been disclosed in CPython’s widely used XML parsing libraries, allowing attackers to weaponize crafted XML documents to exhaust CPU resources and crash applications with no authentication required.
Tracked as CVE-2026-7210, the flaw resides in two of Python’s most commonly used XML parsing components: xml.parsers.expat and xml.etree.ElementTree.
Both libraries rely on the underlying libexpat C library for XML parsing. The problem lies in how they seed their internal hash tables with insufficient entropy, making the hash salt predictable enough for a skilled attacker to reverse-engineer.
Hash flooding is a well-understood class of denial-of-service (DoS) attack. When an XML parser builds its internal hash tables, it uses a salt value to randomize hash outputs and prevent collisions.
If that salt uses too little entropy, an adversary can deliberately craft an XML document whose keys all hash to the same bucket, forcing the parser to degrade from O(1) to O(n²) performance. The result: massive CPU consumption, application hangs, and potential service outages.
According to the Python security team, CPython’s pyexpat module calls XML_SetHashSalt, which only passes 4 to 8 bytes of entropy (depending on architecture) to libexpat’s hash protection mechanism. That is dangerously below the cryptographic threshold needed to resist a targeted hash-flooding attack.
CVE-2026-7210: Python XML Parsers Vulnerability
The deeper root cause lies in libexpat itself. Before version 2.8.0, libexpat used between 4 and 8 bytes of entropy for its internal hash salts, far too little to prevent a determined attacker from predicting hash bucket assignments. This was formally assigned CVE-2026-41080, a companion flaw in the libexpat project that directly underpins the CPython exposure.
Expat 2.8.0, released on April 24, 2026, addressed the root issue by upgrading entropy usage to 16 bytes, a fourfold increase, and added support for the getentropy(3) system call as a high-quality entropy source on Linux, macOS, and WASI platforms.
The release also introduced a new API function, XML_SetHashSalt16Byteswhich replaces the entropy-limited predecessor XML_SetHashSalt. Without this new function, CPython cannot benefit from the stronger entropy even when running against an upgraded libexpat.
This is why the Python security advisory explicitly states that full mitigation requires two steps: updating libexpat to 2.8.0 or later and applying the CPython patch that switches to the new API.
The scope of this vulnerability is broad. Any Python application web service, API gateway, data pipeline, or XML-processing tool:
- Parses untrusted or externally supplied XML input
- Uses
xml.parsers.expatorxml.etree.ElementTree - Runs against a libexpat version older than 2.8.0
This covers cloud-native microservices, legacy enterprise integrations, and even developer tooling that processes XML configuration or SOAP-based payloads. Because xml.etree.ElementTree is the default, built-in XML parser for Python; the attack surface extends across virtually every Python version currently in active use.
Debian’s security tracker has also independently registered the vulnerability, and downstream Linux distributions are expected to push updated packages shortly.
An attacker targeting a vulnerable Python web service would only need to send a specially crafted XML document to any exposed endpoint that feeds data into the parser. The document itself contains no malicious code; it just uses strategically structured XML keys that collide on the weakly seeded hash table.
The parser then spends exponential CPU time resolving those collisions, spiking the server’s load average and effectively taking the service offline. Because no authentication is needed and the payload can be delivered over standard HTTP, this attack is trivially automatable and highly scalable.
Remediation
Fully closing CVE-2026-7210 requires a coordinated fix at both the system and application layers:
- Update libexpat to 2.8.0 or later – Available via package managers (
apt,yum,brew) and directly from the libexpat GitHub releases page - Apply the CPython patch – The official fix is tracked in CPython pull request #149023, which updates
pyexpatto callXML_SetHashSalt16Bytesinstead of the legacy API - Rebuild Python against the updated libexpat – If Python was statically linked with the old libexpat, a system-level library update alone is insufficient; Python must be relinked
- Validate XML input size and complexity – As a temporary defense-in-depth measure, rate-limit or reject abnormally large or deeply structured XML payloads at the application or WAF layer
- Monitor CPU spikes in XML-parsing services – Unusual processing time on endpoints handling XML input may indicate active exploitation attempts
FAQ
Q1: Does CVE-2026-7210 allow remote code execution?
No, it is a denial-of-service vulnerability that causes CPU exhaustion, not code execution.
Q2: Is xml.etree.ElementTree safe if I only parse trusted XML?
Yes, the risk only materializes when parsing XML from untrusted or attacker-controlled sources.
Q3: Will upgrading libexpat alone fix the issue?
No, the CPython patch must also be applied to switch to the new XML_SetHashSalt16Bytes API; both fixes are required for full mitigation.
Q4: Which Python versions are affected?
All CPython versions that bundle or link against libexpat versions earlier than 2.8.0 are affected; check the live CVE record at cve.org for the confirmed version matrix.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
