CVE-2026-50219

What it actually does

libexpat before 2.8.2 can mishandle reentrant calls made from XML event handlers to APIs such as XML_GetBuffer, XML_Parse, XML_ParseBuffer, XML_ParserFree, or XML_ParserReset when a parser policy violation occurs. Because handler call depth is not tracked correctly in those paths, parser state can be freed or reset while still in use, leading to a use-after-free condition. Successful exploitation may allow a local attacker or attacker-controlled local input path to cause crashes or limited confidentiality/integrity impact in software that parses XML with vulnerable libexpat versions.

Why it matters to the business

Applications that rely on vulnerable libexpat builds may become unstable or expose limited data tampering or disclosure risk when processing malicious XML content. The CVSS and EPSS values indicate lower current exploitation likelihood and no known CISA KEV listing, but libexpat is widely embedded in operating systems, runtimes, and applications, so exposure can be indirect through bundled or statically linked dependencies.

How an attack unfolds

An attacker first needs a path where attacker-controlled XML is parsed by an application using libexpat before 2.8.2. The attacker crafts XML that triggers a parser policy violation while causing application-defined XML handlers to make reentrant calls into libexpat APIs such as XML_Parse, XML_ParseBuffer, XML_GetBuffer, XML_ParserFree, or XML_ParserReset. In vulnerable versions, libexpat does not adequately track handler call depth in this scenario, so parser memory or state can be freed or reset while still referenced. The likely outcome is a controlled crash or unstable behavior; depending on allocator behavior, application design, and exploit reliability, limited data disclosure or modification may be possible. No public exploit maturity or known active exploitation is indicated in the provided data.

How to fix it

Upgrade libexpat to version 2.8.2 or later wherever it is installed, bundled, vendored, or statically linked. Because fixed package versions were not provided, use the vendor-maintained package version that explicitly incorporates the upstream libexpat 2.8.2 fix or later. Rebuild applications that statically link or vendor libexpat, update container base images, and refresh language runtime or OS packages that include libexpat. If immediate upgrade is not possible, reduce exposure by limiting untrusted XML processing, disabling unnecessary XML ingestion features, isolating XML parsing workloads, and applying process sandboxing, memory-safe runtime hardening, and crash-restart controls.

How to confirm the fix worked

Confirm that all runtime and build-time copies of libexpat report version 2.8.2 or later, or that the operating-system vendor package includes the corresponding backported fix. Check dynamically linked applications with platform tooling such as package managers, software composition analysis, ldd/otool, container image scanners, and SBOMs. For statically linked software, verify vendor advisories, build manifests, dependency lockfiles, and binary provenance. Regression-test XML parsing functionality, especially code paths using custom handlers that call XML_Parse, XML_ParseBuffer, XML_GetBuffer, XML_ParserFree, or XML_ParserReset from inside callbacks. Confirm crash telemetry no longer shows parser crashes when processing malformed or policy-violating XML.

Typical attack path

1. Identify an application, service, command-line tool, or library workflow that parses XML using libexpat before 2.8.2.
2. Find an input path where XML content can be supplied locally or through a local processing workflow.
3. Craft XML and parser interaction conditions that trigger a policy violation during handler execution.
4. Cause the application’s XML handlers to invoke vulnerable reentrant libexpat APIs such as XML_Parse, XML_ParseBuffer, XML_GetBuffer, XML_ParserFree, or XML_ParserReset.
5. Trigger the use-after-free condition and attempt to crash the process or influence memory state for limited confidentiality, integrity, or availability impact.

How to detect it

There are no unique network or host indicators that reliably prove exploitation of this library flaw. Detection should focus on evidence of attempted malicious XML processing and resulting process instability. Review application logs, crash dumps, core files, EDR telemetry, system journals, and file-processing audit logs for crashes or abnormal termination immediately after XML ingestion. Look for stack traces involving libexpat and reentrant parser APIs, especially XML_GetBuffer, XML_Parse, XML_ParseBuffer, XML_ParserFree, or XML_ParserReset. Correlate crashes with newly received XML files, uploaded documents, automated import jobs, local batch processing, or user-submitted content. Preserve suspicious XML samples and crash artifacts for reproduction in an isolated environment. Because no known exploitation or threat actors are identified in the provided data, treat detections as suspicious only when tied to malformed XML input and libexpat crash behavior.

What your security team should do

• Inventory all systems, containers, appliances, and applications that include libexpat, including embedded and statically linked copies.
• Prioritize upgrades for internet-facing, multi-user, automated file-processing, document-processing, and security-sensitive applications that parse untrusted XML.
• Upgrade to libexpat 2.8.2 or a vendor package with the backported fix, then rebuild and redeploy dependent applications and images.
• Use software composition analysis and SBOM review to identify transitive exposure in third-party products and internally built software.
• Monitor application crash logs and EDR telemetry for XML parsing crashes or abnormal process termination in workflows that handle untrusted XML.
• Where upgrades are delayed, sandbox XML parsing components and restrict untrusted XML inputs to reduce blast radius.