libexpat xmlwf CVE-2026-56409

The vulnerability is triggered only when the xmlwf command-line tool is invoked with the -d outputDir flag AND the combined byte length of the output directory path and the XML input filename approaches the platform's SIZE_MAX / sizeof(XML_Char) threshold - a condition requiring abnormally long path strings. Both the additive sum tcslen(outputDir) + tcslen(file) + 2 and the multiplicative step * sizeof(XML_Char) must each be individually guarded (as the fix demonstrates), meaning either stage can be the overflow point. Exploitation is limited to local execution (AV:L), requires a user or automated process to actively run the tool (UI:R), and demands high complexity to construct suitable path lengths (AC:H). The core libexpat API used by linked applications is entirely unaffected - only the standalone xmlwf binary is vulnerable, and only when the -d flag is present.

The CVSS 3.1 score of 6.5 (AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L) accurately reflects the constrained exploitation profile: local access, high attack complexity, and mandatory user interaction all bound practical risk despite the elevated C:H/I:H impact ratings. AC:H is well-supported by the fix code - triggering the overflow requires that the combined outputDir and filename lengths approach SIZE_MAX / sizeof(XML_Char), a condition difficult to achieve in typical usage. No EPSS score was provided, KEV listing is absent, and no public POC has been identified - all signals point to low near-term exploitation probability. However, risk escalates in environments where xmlwf is invoked programmatically in CI/CD pipelines or document processing workflows that accept external file paths, since user-interaction and complexity requirements may be met by design in such contexts. The C:H/I:H impact is credible only if heap exploitation succeeds; crashing the tool (denial of service) is a more likely immediate outcome.

An attacker with influence over the outputDir argument or over filenames processed by an automated xmlwf pipeline supplies a directory path or filename whose combined length with the XML input filename approaches the size_t maximum. When xmlwf runs with -d <attacker-controlled-path>, the addition tcslen(outputDir) + tcslen(file) + 2 wraps to a near-zero value, malloc() allocates a tiny heap buffer, and the subsequent filename string copy overflows it - potentially corrupting adjacent heap metadata and enabling code execution in the context of the process running xmlwf. No public exploit code exists at time of analysis, but the integer-overflow-to-heap-overflow primitive is well-documented in exploitation literature.