CVE-2026-56412

What it actually does

libexpat before 2.8.2 can mishandle handler call-depth tracking while processing CDATA content, specifically because XML_TOK_DATA_CHARS was not fully accounted for in doCdataSection during policy-violation handling. Under specific parser-callback conditions, a crafted XML document can cause libexpat to access memory after it has been freed. The likely technical outcomes are parser crash, application denial of service, or limited memory corruption with possible low-impact confidentiality or integrity effects depending on how the embedding application handles XML parsing and memory safety protections.

Why it matters to the business

Applications, services, or desktop tools that parse untrusted XML with a vulnerable libexpat version may be destabilized by specially crafted input. The risk is lower than many remotely exploitable server-side flaws because exploitation is high-complexity, currently has no known public exploit maturity, is not in the CISA Known Exploited Vulnerabilities catalog, and has a very low EPSS score. However, libexpat is widely embedded in operating systems, language runtimes, middleware, and third-party products, so organizations should treat this as a dependency hygiene issue and prioritize updates where XML is processed from users, partners, file uploads, email attachments, data feeds, or automated import pipelines.

How an attack unfolds

An attacker first identifies software that uses a vulnerable libexpat release to parse XML and has a path for attacker-controlled XML to reach that parser, such as a local file import, queued job, document-processing workflow, or another application-specific ingestion path. The attacker then crafts XML containing CDATA content intended to trigger a policy-violation path and nested or reentrant parser-handler behavior where call depth is not tracked correctly. When the vulnerable parser processes the document, internal memory can be freed while still being referenced, resulting in a use-after-free condition. In practical terms, exploitation is expected to be fragile and environment-dependent: the most reliable outcome is likely an application crash, while controlled memory corruption or data impact would require favorable application behavior, allocator state, and bypasses for modern memory protections. There is no indication from the supplied data that this vulnerability is being exploited in the wild or used by ransomware campaigns.

How to fix it

Upgrade libexpat to version 2.8.2 or later wherever it is installed, bundled, statically linked, or vendored into applications. Because libexpat is commonly included indirectly, update operating system packages, container base images, language runtime packages, application dependencies, appliances, and third-party software that ship their own libexpat copy. Rebuild and redeploy applications that statically link libexpat so they do not continue using the vulnerable code after the system package is updated. Where immediate upgrading is not possible, reduce exposure by rejecting or quarantining untrusted XML, disabling unnecessary XML import features, enforcing strict file-size and parser limits, running XML-processing workloads in least-privilege sandboxes, and isolating document-conversion or ingestion services from sensitive systems.

How to confirm the fix worked

Confirm the deployed libexpat runtime is version 2.8.2 or later using package-manager queries, SBOM data, binary inspection, and runtime dependency checks. Useful validation methods include checking OS package versions, running available version commands such as xmlwf -v or expat-config --version where present, inspecting dynamically linked binaries with ldd/otool/readelf, and searching source trees or build artifacts for bundled expat copies. Validate containers and appliances separately because they may carry independent vulnerable copies. For applications built from source, confirm the build logs and final artifacts link against the updated library. If a vendor supplies a regression test or proof-of-concept trigger, run it in a controlled non-production environment and verify the application no longer crashes or reports use-after-free behavior under sanitizers.

Typical attack path

1. Find an application, service, library, or tool that embeds libexpat before version 2.8.2.
2. Confirm that the target processes attacker-controlled XML through libexpat, directly or through a dependent framework or product.
3. Craft an XML document with CDATA content designed to exercise the vulnerable doCdataSection policy-violation path and parser-handler call behavior.
4. Deliver the XML through a supported local or application-level input path, such as file import, document processing, upload workflow, package metadata, configuration ingestion, or automated feed processing.
5. Trigger parsing of the malicious XML so the use-after-free condition occurs.
6. Leverage the resulting crash or memory corruption for denial of service, limited data exposure, or limited data modification depending on the embedding application and runtime protections.

How to detect it

To assess possible prior exploitation, review telemetry from applications that parse XML, especially file-import services, document processors, data-ingestion workers, CI/CD tooling, middleware, and products that accept XML-based formats. Look for crashes, abnormal exits, segmentation faults, heap corruption reports, sanitizer findings, or EDR alerts occurring shortly after XML file handling. Relevant log sources include application logs, system logs, kernel crash messages, Windows Application Event Logs, Linux journald/syslog, container runtime logs, EDR process telemetry, core-dump services, crash reporters, and document-processing job queues. Focus on stack traces or crash frames referencing libexpat, XML_Parse, doCdataSection, XML_GetBuffer, XML_StopParser, or CDATA parsing. Review recently processed XML files around crash times for unusual CDATA sections, repeated parser callbacks, oversized or malformed XML, and inputs from untrusted users or automated feeds. There are no known CVE-specific network signatures or public exploit indicators from the supplied data, so detection should be behavior- and crash-centric rather than signature-only.

• libexpat
• XML_Parse
• doCdataSection
• XML_TOK_DATA_CHARS
• XML_StopParser
• XML_GetBuffer
• CDATA
• heap-use-after-free
• AddressSanitizer: heap-use-after-free
• use-after-free
• Segmentation fault
• SIGSEGV
• double free or corruption
• corrupted size vs. prev_size
• malloc(): memory corruption
• free(): invalid pointer

What your security team should do

• Inventory systems, applications, containers, and third-party products that include libexpat, prioritizing components that parse XML from untrusted or semi-trusted sources.
• Upgrade libexpat to 2.8.2 or later and rebuild any statically linked or vendored applications.
• Prioritize externally reachable ingestion workflows, document-processing services, file-upload pipelines, partner data feeds, and automated XML import jobs even though the CVSS and EPSS indicate relatively low immediate exploitation likelihood.
• Ask vendors of appliances, commercial applications, and embedded products whether their software bundles libexpat and whether their fixed release includes libexpat 2.8.2 or later.
• Add compensating controls for unpatched systems, including XML input restrictions, sandboxing, least-privilege execution, crash monitoring, and queue isolation for document-processing workloads.
• Monitor application, kernel, EDR, and crash-reporting telemetry for unexplained crashes in XML-processing components or stack traces involving libexpat parsing functions.
• Track threat intelligence for any change in exploit maturity, EPSS trajectory, or KEV status because broadly embedded parser vulnerabilities can become more urgent if reliable exploit techniques are published.