CVE-2026-56409

What it actually does

The flaw is an integer overflow in the libexpat xmlwf command-line tool when it constructs an output filename while the -d outputDir option is used. If xmlwf is invoked on attacker-influenced input or paths, arithmetic used to size or build the output path can wrap, leading to memory corruption. Depending on build options, platform protections, and exploit reliability, this may result in xmlwf crashing, reading or writing unintended memory, or potentially executing attacker-controlled code with the privileges of the user or automation running xmlwf. The issue affects libexpat before 2.8.2.

Why it matters to the business

Organizations that use xmlwf in developer tooling, content-processing workflows, CI jobs, packaging pipelines, or automated XML validation may be exposed if those workflows process untrusted files or filenames. Successful exploitation could disrupt XML processing and, in a worst case, allow compromise of the account running the tool, which may expose source code, build artifacts, credentials, or processed data. The current EPSS is low and the issue is not listed in CISA KEV, indicating no broad public exploitation signal from the provided data, but libexpat is widely embedded and should still be remediated through normal patch cycles, especially where automated processing handles external files.

How an attack unfolds

An attacker first needs a path to influence how xmlwf is invoked, such as convincing a user to run xmlwf manually, contributing a crafted file or filename to a repository or archive that is processed by automation, or placing XML content into a workflow that calls xmlwf with the -d outputDir option. The attacker supplies input that causes xmlwf to build an unusually large or malformed output filename. In vulnerable versions before 2.8.2, the filename length calculation can overflow, causing allocation or copy logic to operate on an incorrect size. The immediate outcome may be a crash, but with sufficient control over memory layout and execution context, the attacker may be able to corrupt memory in a way that affects confidentiality or integrity under the xmlwf process account. Exploitation is local/user-assisted and high-complexity rather than remotely wormable based on the provided CVSS vector.

How to fix it

Upgrade libexpat to version 2.8.2 or later wherever xmlwf is installed or bundled. Because libexpat is commonly packaged, embedded, or statically linked, update operating-system packages, language/runtime dependencies, build images, containers, appliances, and any vendor products that ship their own copy. If immediate upgrade is not possible, reduce exposure by avoiding xmlwf on untrusted files, disabling or removing automated workflows that invoke xmlwf with -d, restricting who can submit files or filenames to those workflows, and running XML validation in a sandboxed, least-privileged environment. Apply compiler and runtime hardening where applicable, including ASLR, stack protections, fortified libc, and non-executable memory, but treat these as risk reduction rather than a fix.

How to confirm the fix worked

Confirm that installed and bundled libexpat versions are 2.8.2 or later. Use package manager queries such as rpm -q expat, dpkg -l '*expat*', apk info expat, brew info expat, or equivalent platform tooling, and verify xmlwf version output where available. Search containers, build images, developer workstations, and CI runners for xmlwf binaries and embedded libexpat libraries. For source builds or statically linked binaries, validate SBOMs, build manifests, vendor advisories, or binary metadata rather than relying only on OS package versions. Confirm that workflows no longer execute vulnerable xmlwf with -d against untrusted input, and retest representative XML-validation jobs after upgrading.

Typical attack path

1. Identify a system, user workflow, build pipeline, or content-processing job that runs xmlwf from libexpat before 2.8.2.
2. Determine whether xmlwf is invoked with the -d outputDir option while processing attacker-controlled XML files, filenames, directory names, archives, or repository content.
3. Prepare input that causes xmlwf to construct an oversized output filename and trigger the integer overflow.
4. Deliver the crafted file or path through social engineering, source contribution, archive upload, local filesystem access, or another workflow-specific mechanism.
5. Wait for a user or automation to execute xmlwf with -d against the crafted input.
6. Trigger memory corruption in the xmlwf process, causing a crash or attempting controlled code execution with the privileges of the invoking user or service account.

How to detect it

There are no provided public exploitation indicators, no KEV listing, and no named threat actors for this issue, so detection should focus on suspicious use and crash evidence rather than known campaign IOCs. Review EDR process creation, shell history, CI/build logs, task scheduler logs, container logs, and auditd/Sysmon telemetry for xmlwf executions containing the -d option, especially where arguments include unusually long paths, externally supplied filenames, extracted archive paths, or repository-controlled content. Review Linux kernel logs, systemd-coredump, apport, ABRT, macOS crash reports, Windows application error logs, and EDR crash telemetry for xmlwf segmentation faults, access violations, aborts, or core dumps. If a suspicious crash is found, preserve the XML input, filename/path metadata, command line, working directory, parent process, environment, core dump, and user context. Also check whether the invoking account accessed unusual files, spawned child processes, wrote unexpected output, or used credentials after the crash, as those may indicate successful exploitation beyond denial of service.

• xmlwf -d
• /usr/bin/xmlwf
• /usr/local/bin/xmlwf
• /bin/xmlwf
• comm="xmlwf"
• process_name=xmlwf
• Image: xmlwf
• CommandLine=*xmlwf* -d *
• kernel: xmlwf
• segfault at
• systemd-coredump
• Process xmlwf dumped core
• core.xmlwf
• apport: program crashed: xmlwf
• abrt-hook-ccpp
• Exception Code: 0xc0000005
• Access violation
• Segmentation fault
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: SEGV

What your security team should do

• Inventory systems, containers, CI runners, developer images, and packaged products that include libexpat xmlwf before 2.8.2.
• Prioritize remediation for workflows that run xmlwf with -d on files, filenames, archives, repositories, or content supplied by external or low-trust users.
• Upgrade libexpat to 2.8.2 or later and rebuild any statically linked applications or images that include vulnerable copies.
• Temporarily disable, sandbox, or restrict xmlwf -d usage where patching cannot be completed quickly.
• Add EDR/SIEM visibility for xmlwf process execution, especially command lines containing -d and unusually long directory or filename arguments.
• Review recent crash, core dump, and process execution telemetry for xmlwf to determine whether malformed inputs may already have triggered the vulnerability.
• Track vendor advisories for downstream products that bundle libexpat because affected copies may not be visible through normal OS package inventory.