CVE-2026-56410

What it actually does

The flaw is an integer overflow in xmlwf, the command-line XML well-formedness checker shipped with libexpat, in the resolveSystemId logic used while handling system identifiers. If xmlwf processes a specially crafted XML input, arithmetic on attacker-influenced identifier lengths can wrap and lead to incorrect buffer sizing or memory handling. The practical result is memory corruption that can cause a crash and, depending on platform hardening, compiler behavior, and build options, may create a path to arbitrary code execution in the context of the user or automation account running xmlwf. The vulnerable code is in the xmlwf utility rather than the core parser API, so exposure is highest where xmlwf is installed and used directly or through automated validation pipelines.

Why it matters to the business

Organizations that use xmlwf to validate XML files, especially in build systems, document-processing workflows, ingestion pipelines, package validation, or automated quality checks, could have those processes crashed or potentially compromised by a malicious XML file. Because the issue is not in CISA KEV, has no known public exploit maturity, and has a low EPSS score, broad active exploitation is not currently indicated; however, libexpat is a common component and downstream packaging can make exposure easy to overlook. The main operational risk is compromise of developer, CI/CD, or processing environments that run xmlwf on untrusted XML content.

How an attack unfolds

An attacker first identifies a path where XML content they control is passed to the xmlwf utility, such as a file upload validation job, CI pipeline, package linting process, or local command executed by another workflow. They craft an XML document containing a maliciously sized or structured system identifier intended to trigger integer overflow in resolveSystemId. When vulnerable xmlwf versions before 2.8.2 process the file, the overflow can corrupt memory. In the most likely outcome, xmlwf terminates abnormally and disrupts the workflow. In a more advanced scenario, the attacker shapes memory corruption to influence control flow and execute code with the permissions of the xmlwf process. There is no current indication from the supplied intelligence that this vulnerability is being exploited in the wild or used in ransomware campaigns.

How to fix it

Upgrade libexpat/xmlwf to version 2.8.2 or later wherever xmlwf is installed or bundled. Because the supplied fixed_versions field is empty but the vulnerability description states that versions before 2.8.2 are affected, treat 2.8.2 as the minimum safe upstream version. Update operating system packages, container base images, language/runtime distributions, SDKs, build images, and third-party tools that include libexpat or xmlwf. Rebuild statically linked or vendored copies, as package upgrades may not affect embedded binaries. If immediate upgrade is not possible, reduce exposure by preventing xmlwf from processing untrusted XML, disabling automated xmlwf validation on external inputs, running xmlwf in a sandbox or container with minimal privileges, enforcing resource limits, and isolating validation jobs from sensitive credentials and build secrets.

How to confirm the fix worked

Confirm that xmlwf and the associated libexpat package report version 2.8.2 or later. Use package-manager inventory, software composition analysis, container image scans, and direct binary checks to locate both dynamically installed and vendored copies. Where available, run commands such as xmlwf -v, package queries for expat/libexpat, and SBOM searches for libexpat versions earlier than 2.8.2. Verify that CI/CD images, developer workstations, XML-processing servers, and document-validation systems have been rebuilt against the fixed version. For mitigations, confirm that untrusted XML input no longer reaches xmlwf, that sandboxing is enforced, and that the xmlwf process runs without elevated privileges or access to sensitive credentials.

Typical attack path

1. Find an application, automation job, CI/CD pipeline, or user workflow that invokes xmlwf on XML files from untrusted or semi-trusted sources.
2. Create a malformed XML document with a crafted system identifier designed to trigger the integer overflow in resolveSystemId.
3. Submit, upload, commit, or otherwise place the XML file where the vulnerable xmlwf utility will process it.
4. Trigger XML validation or wait for the automated process to run xmlwf.
5. Cause xmlwf to crash or, in a more sophisticated exploit, achieve memory corruption leading to code execution in the context of the invoking account.
6. Use the resulting access to read accessible files, alter processing outputs, tamper with build artifacts, or pivot within the local environment if privileges and controls permit.

How to detect it

Look for evidence that xmlwf processed suspicious or untrusted XML followed by a crash, core dump, sanitizer finding, or unexpected child process. Useful sources include process creation telemetry, EDR events, shell history, CI/CD job logs, application validation logs, systemd/journald, syslog, Windows Event Logs where applicable, container runtime logs, crash dump directories, and core dump metadata. Correlate xmlwf executions with recently uploaded, downloaded, committed, or queued XML files, especially files containing unusually long system identifiers, DOCTYPE declarations, external entity references, or abnormal path/URI strings. Because no public exploit indicators or threat actors are supplied, detection should focus on behavioral signs of attempted memory corruption rather than fixed network indicators. Investigate any xmlwf crash that occurs while processing external XML, any xmlwf process spawning shells or network tools, and any access to sensitive files immediately after an xmlwf invocation.

• process_name=xmlwf
• comm="xmlwf"
• argv contains "xmlwf"
• "xmlwf" "Segmentation fault"
• "xmlwf" "core dumped"
• "xmlwf" "AddressSanitizer"
• "xmlwf" "runtime error: signed integer overflow"
• "xmlwf" "integer overflow"
• "resolveSystemId"
• "DOCTYPE" "SYSTEM"
• "<!ENTITY" "SYSTEM"
• /usr/bin/xmlwf
• /usr/local/bin/xmlwf
• /var/lib/systemd/coredump/ core xmlwf
• core.xmlwf

What your security team should do

• Inventory all installations of libexpat and xmlwf, including OS packages, containers, build images, SDKs, appliances, and vendored/static copies.
• Prioritize upgrades to libexpat/xmlwf 2.8.2 or later on systems that process XML from external users, partners, source repositories, document queues, or automated build workflows.
• Treat developer tooling and CI/CD environments as important exposure points because compromise there can affect software supply chain integrity.
• Add guardrails so xmlwf is not run on untrusted XML outside a sandbox with least privilege, restricted filesystem access, and no access to production secrets.
• Monitor for abnormal xmlwf crashes, core dumps, segmentation faults, or sanitizer reports, especially after processing newly received XML files.
• Review recent automation logs for unexpected xmlwf invocations against externally supplied XML content since publication on 2026-06-21.
• Track vendor advisories and downstream package releases because fixed package versions may differ by distribution even when the upstream fixed version is 2.8.2.