libexpat xmlwf CVE-2026-56410

Exploitation requires three concurrent conditions: (1) the target system must be running libexpat earlier than 2.8.2 specifically compiled for a 32-bit architecture (on 64-bit platforms, causing a size_t overflow via string lengths is practically infeasible without extraordinary path lengths exceeding petabytes); (2) the xmlwf command-line tool - not the libexpat core library - must be invoked by the victim or an automated process, meaning this code path is triggered only by xmlwf's resolveSystemId function, not by applications embedding libexpat for XML parsing; (3) the attacker must supply or influence both the XML file content (systemId in DOCTYPE SYSTEM declaration) and/or the base path argument to xmlwf such that their combined character lengths approach SIZE_MAX. Applications that use libexpat as a parsing library but do not call xmlwf are NOT affected by this specific vulnerability. Absence of authentication requirements follows from xmlwf being a local command-line tool (PR:N per CVSS), but local execution context is required.

The CVSS 3.1 base score of 6.9 with vector AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L signals a locally exploitable, high-complexity flaw with potentially severe memory-corruption impact. The AV:L constraint limits exposure significantly - remote unauthenticated exploitation is not indicated. AC:H reflects that triggering the overflow requires specially constructed, very long base-path and systemId strings that together approach or exceed the size_t boundary, a condition that is practically much harder on 64-bit platforms (where size_t is 64 bits and SIZE_MAX is ~18 EB) but more feasible on 32-bit builds. No EPSS score was provided in source data; no CISA KEV listing or public exploit code was identified, which aligns with the AC:H complexity assessment. The real-world priority depends heavily on whether libexpat is deployed in builds that invoke xmlwf (the command-line tool, not the core parsing library) in pipelines where input XML or base paths are externally influenced. Libraries embedding libexpat for parsing (but not using xmlwf directly) are not affected by this specific code path. Net assessment: moderate priority - patch promptly in environments running xmlwf on untrusted input; lower urgency otherwise.

An attacker with local access crafts an XML file containing a DOCTYPE declaration with an artificially long SYSTEM identifier - long enough that when combined with the base path, the combined length arithmetic overflows size_t. When a developer, CI pipeline, or build script runs xmlwf against this file (e.g., xmlwf -b /very/long/base/path malicious.xml), resolveSystemId performs the unchecked malloc with a wrapped-around (undersized) buffer, and the subsequent string copy writes beyond the heap allocation. On 32-bit libexpat builds this overflow boundary is reachable at roughly 4 GB of combined string length, though in practice heap-spray or other memory layout techniques may lower the required length to achieve controlled overwrite.