CVE-2026-56411

What it actually does

CVE-2026-56411 is an integer overflow in the libexpat xmlwf utility before version 2.8.2, triggered while processing XML Document Type Definition (DTD) NOTATION declarations in endDoctypeDecl. A crafted XML document can cause incorrect size calculations and memory corruption during parsing. Depending on compiler, platform, allocator behavior, and runtime protections, exploitation may result in process crash, information disclosure, or potentially arbitrary code execution in the security context of the xmlwf process or any workflow that invokes the vulnerable parser path. The CVSS vector indicates local attack surface, high attack complexity, no privileges required, no user interaction, and high confidentiality and integrity impact with low availability impact.

Why it matters to the business

Organizations that process XML files using vulnerable libexpat tooling may be exposed to compromise if attackers can introduce crafted XML into local processing workflows, build pipelines, validation jobs, security scanners, document import processes, or automation that invokes xmlwf. Successful exploitation could allow an attacker to disrupt XML processing or, in a worst case, execute code with the privileges of the parsing process, potentially leading to data theft, tampering, or lateral movement from systems that handle untrusted XML. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad active exploitation is not indicated; however, libexpat is widely embedded and should be patched where present because parser flaws can be inherited by downstream tools and distributions.

How an attack unfolds

An attacker first identifies a system, package, application, or automation workflow that uses xmlwf from libexpat before 2.8.2 to validate or parse XML content. The attacker then crafts an XML file containing DTD NOTATION declarations designed to trigger an integer overflow in endDoctypeDecl. The crafted file must be supplied to a context where xmlwf parses attacker-controlled XML, such as a local command invocation, automated validation job, file-processing pipeline, repository hook, import routine, or other workflow that accepts XML input. When the vulnerable parser reaches the end of the DOCTYPE declaration, the overflow can corrupt memory. The most likely observable outcome is a crash of xmlwf, but under favorable conditions an attacker may be able to shape memory corruption to disclose information or execute code under the privileges of the process performing XML validation.

How to fix it

Upgrade libexpat and xmlwf to version 2.8.2 or later wherever they are installed or bundled. Because fixed_versions was not provided as package-specific data, use the vendor, operating system distribution, language runtime, appliance, container base image, or embedded software advisory to identify the exact patched package. Rebuild or redeploy statically linked applications and containers that include libexpat, as updating the system shared library alone may not protect embedded copies. If immediate patching is not possible, reduce exposure by preventing xmlwf from processing untrusted XML, disabling DTD processing where feasible in dependent workflows, isolating XML validation in a sandbox or low-privilege container, enforcing file provenance controls, and monitoring for crashes or anomalous xmlwf executions.

How to confirm the fix worked

Confirm that xmlwf reports libexpat version 2.8.2 or later using commands such as `xmlwf -v`, operating system package inventory, software composition analysis, or container image scanning. On Linux and Unix-like systems, verify whether applications dynamically link to libexpat with tools such as `ldd`, package manager queries, or SBOM results, and separately check for statically linked or vendored copies. Validate that patched packages are present in all runtime images, CI/build images, developer tooling images, appliances, and XML-processing utilities. Do not run public proof-of-concept or crash-triggering files in production; if exploit validation is required, use an isolated test environment and confirm that malformed NOTATION-heavy XML no longer causes xmlwf crashes or sanitizer findings.

Typical attack path

1. Identify systems or workflows that invoke vulnerable xmlwf/libexpat versions before 2.8.2.
2. Gain the ability to place or submit XML content that will be parsed by xmlwf or a dependent workflow.
3. Create a malicious XML document containing crafted DTD NOTATION declarations.
4. Trigger parsing of the malicious XML through a local invocation, automation job, validation process, or file-processing pipeline.
5. Exploit the integer overflow in endDoctypeDecl to cause memory corruption.
6. Use the resulting crash, information disclosure, or potential code execution to disrupt processing or gain further access.

How to detect it

To determine whether exploitation was already attempted, review endpoint detection telemetry, process creation logs, shell history, job scheduler logs, CI/CD logs, application import logs, and system crash logs for xmlwf executions against unusual or externally supplied XML files. Look for repeated xmlwf crashes, segmentation faults, abnormal exits, core dumps, allocator corruption errors, or sanitizer reports occurring shortly after XML validation. Inspect suspicious XML files for DTD sections containing NOTATION declarations, especially unusually large, repeated, deeply nested, or malformed declarations. On Linux systems, review syslog, journald, auditd, kernel logs, coredumpctl output, apport/ABRT crash reports, and EDR telemetry for xmlwf faults. On macOS, review Unified Logs and crash reports for xmlwf. In build and automation environments, correlate xmlwf failures with recently submitted XML artifacts, repository commits, uploaded documents, or pipeline inputs. No public threat actors or ransomware campaigns are currently associated with this vulnerability based on the provided data, so detection should focus on local parser crashes and malformed XML artifacts rather than actor-specific infrastructure.

• xmlwf
• <!NOTATION
• NOTATION
• <!DOCTYPE
• endDoctypeDecl
• Segmentation fault
• segfault.*xmlwf
• core dumped.*xmlwf
• malloc(): corrupted
• double free or corruption
• AddressSanitizer.*xmlwf
• heap-buffer-overflow
• integer overflow
• libexpat.so
• libexpat.dylib
• expat.dll

What your security team should do

• Inventory libexpat and xmlwf usage across servers, developer workstations, containers, build systems, CI/CD runners, scanners, and applications that process XML.
• Prioritize upgrades to libexpat/xmlwf 2.8.2 or later, especially on systems that parse XML from untrusted sources or automated file-ingestion workflows.
• Search SBOMs, package inventories, and container images for bundled or statically linked libexpat copies that may not be fixed by normal OS package updates.
• Restrict xmlwf execution and XML validation jobs to least-privilege accounts and sandboxed environments.
• Disable or restrict DTD processing in XML workflows where business functionality does not require it.
• Monitor endpoint, application, and system logs for xmlwf crashes, segmentation faults, allocator corruption messages, and repeated parsing failures involving DTD or NOTATION declarations.
• Treat any suspicious xmlwf crash associated with externally supplied XML as a potential exploitation attempt and preserve the input file, process metadata, and crash artifacts for analysis.