The 2MB Assassin: Inside the Unfixed libexpat DoS (CVE-2025-66382)

If you are reading this, you are almost certainly running code that depends on libexpat. It is the parsing engine under the hood of Python's xml.etree, PHP's XML extensions, the Apache HTTP server, Mozilla Firefox, and roughly a billion embedded devices. It is the definition of "critical infrastructure" in the open-source world.

Usually, when we talk about libexpat vulnerabilities, we are terrified of Remote Code Execution (RCE) via heap overflows. But CVE-2025-66382 is a different beast. It is not about corrupting memory; it is about wasting time. Specifically, your CPU's time.

Imagine a bouncer at a club who checks IDs. Normally, it takes 5 seconds per person. This vulnerability is like handing the bouncer an ID printed on a Mobius strip. He doesn't crash, he doesn't die, he just stands there staring at it for two minutes while the line outside (your network traffic) grows infinitely long. The scariest part? As of early 2026, the bouncer still hasn't figured out how to stop staring.

The vulnerability falls under CWE-407: Inefficient Algorithmic Complexity. In plain English, this means the developers implemented a feature where the processing time grows disproportionately to the input size.

Most parsing operations should be linear, or $O(n)$. You read a byte, you process a byte. If you double the file size, you double the processing time. However, somewhere deep in libexpat's logic—likely involving attribute normalization, namespace resolution, or entity tracking—there is a loop that behaves quadratically, $O(n^2)$, or perhaps even worse.

Here is the math of the nightmare:

• Input: A ~2 MiB XML file (trivial size for modern bandwidth).
• Processing Time: 25 to 100 seconds.

That is an eternity in CPU time. If an attacker sends just one of these files per second, they can permanently pin 25-100 CPU cores at 100% utilization. This isn't a "crash"; the process is technically "working correctly," just agonizingly slowly. This makes it incredibly hard for standard watchdogs to detect, as the service hasn't segfaulted—it's just effectively dead.

Usually, this is the part where I show you the diff—the specific lines of C code where the developer forgot a bounds check or messed up a pointer. But I can't do that here. Why? Because there is no fix yet.

Maintainer Sebastian Pipping confirmed the issue affects all releases of libexpat. The complexity of the fix is high enough that, despite being reported in September 2025, the library remains vulnerable in February 2026. However, we can simulate the concept of the flaw.

Imagine a naive implementation of attribute uniqueness checking:

// CONCEPTUAL EXAMPLE OF O(n^2) FAILURE
// This is NOT the actual libexpat code, but illustrates the flaw.
 
void check_attribute_uniqueness(Attribute *attrs, int count) {
    for (int i = 0; i < count; i++) {
        for (int j = i + 1; j < count; j++) {
            // If we have 10,000 attributes, this inner loop runs
            // roughly 50,000,000 times.
            if (strcmp(attrs[i].name, attrs[j].name) == 0) {
                 report_error("Duplicate attribute");
            }
        }
    }
}

In the code above, if an attacker provides an XML tag with 50,000 attributes, the CPU has to perform billions of string comparisons. Modern parsers usually use hash maps to achieve $O(n)$ or $O(n \log n)$ performance.

The actual flaw in libexpat is subtle. It involves a specific, non-public trigger file that hits a "sweet spot" in the parser's state machine, forcing it into a similarly expensive computational hole. The fact that the maintainer described the fix as "not as complex as resolving recursion" but still non-trivial suggests it requires architectural changes to how state is tracked, rather than a simple one-line patch.

Since the specific trigger file is currently under a "freeform NDA" between the researcher and the maintainer, there is no public PoC on GitHub. However, an attacker doesn't need the exact file to understand the attack surface. They just need to fuzz the parser's complexity limits.

The Theoretical Attack Chain

1. Reconnaissance: Identify an endpoint accepting XML. SOAP APIs, SAML authentication endpoints (SSO), and XML-RPC interfaces are prime targets.
2. Delivery: The attacker generates an XML file roughly 2MB in size. This file likely contains thousands of nested entities, specific namespace declarations, or a massive number of attributes designed to trigger the worst-case code path.
3. Execution: The attacker uploads the file. The server accepts it (2MB is usually well within default limits like client_max_body_size).
4. Effect: The parsing thread hangs. It doesn't die. It sits there, burning 100% of a CPU core for nearly two minutes.

If the server is multi-threaded (like Apache Prefork), the attacker only needs to send enough requests to fill the MaxRequestWorkers pool. Once the pool is full of "zombie" workers crunching this 2MB file, the server stops responding to legitimate traffic.

This is the uncomfortable part. There is no apt-get upgrade to save you right now. The vulnerability is "Unfixed" upstream. So, how do you stop your servers from melting?

1. The Stopwatch Defense (Timeouts)

If you can't fix the parser, you must kill the parser. Implement strict timeouts at the application level. No XML parsing operation for a standard web request should take more than 1 or 2 seconds.

• Python: Use signal based timeouts or wrap parsing in a thread with a .join(timeout=2.0).
• Web Servers: Lower your Timeout directives, though this is a blunt instrument that might kill legitimate long requests.

2. Size Limits

The trigger is ~2 MiB. While valid XML can be larger, most transactional XML (SOAP/SAML) is much smaller (under 50KB).

> [!WARNING] > Hard Limit Strategy: Configure your WAF or reverse proxy (Nginx/HAProxy) to reject XML bodies larger than 1MB unless you strictly require them. This kills the known trigger before it reaches libexpat.

3. Monitoring

Set up alerts for CPU Steal or high User CPU usage on your web nodes. If you see a plateau of 100% usage without a corresponding spike in traffic throughput (RPS), you are likely under an algorithmic complexity attack.