CVE-2026-24009

What it actually does

docling-core 2.21.0 through 2.48.3 deserializes YAML in DoclingDocument.load_from_yaml() with PyYAML FullLoader. If the runtime also has PyYAML earlier than 5.4, untrusted YAML can instantiate arbitrary Python objects during load, yielding remote code execution in the document-processing process with high impact to confidentiality, integrity, and availability. This re-exposes CVE-2020-14343; version 2.48.4 switches to SafeLoader so unsafe tags cannot execute code. Reachability requires both the vulnerable library range and the outdated PyYAML plus a call path that feeds untrusted YAML into load_from_yaml().

Why it matters to the business

Document AI, conversion, and ingest pipelines that accept YAML from users, APIs, or files could be fully taken over—data theft, tampering of processed records, outage, or a foothold on the processing host. The issue is not in CISA KEV, has no reported ransomware use, and exploit maturity is none; EPSS is low (~1.56%) though it rose about 11% over 30 days (0.0140 → 0.0156). Attack complexity is high because old PyYAML and the specific API must both be present, but docling-core appears in document-processing stacks and MinimOS linux-virt / linux-virt-doc images. At 250 days after publication, remaining unpatched deployments are an avoidable operational risk.

How an attack unfolds

An attacker who can supply YAML to an application that calls DoclingDocument.load_from_yaml() confirms the target runs docling-core 2.21.0–2.48.3 with PyYAML before 5.4. They then deliver a crafted YAML document over a network-reachable upload, API, or file-drop path. FullLoader interprets unsafe YAML tags that construct Python objects, executing attacker-chosen code as the application user with no privileges or user interaction required. From that process the attacker can read local data, alter documents in the pipeline, or install follow-on tooling. No named threat actors or in-the-wild campaigns are associated with this CVE; exploitation depends on the dual-condition stack, which is why complexity is rated high.

How to fix it

Upgrade docling-core to 2.48.4 or later so YAML load uses SafeLoader instead of FullLoader. If the library cannot be upgraded immediately, install PyYAML 5.4 or greater, which removes the underlying unsafe-load behavior. MinimOS users should move linux-virt and linux-virt-doc to 6.12.47-r0 or later. Source trees can take commit c52605dded70787e647a100a30c85a05c4e989a9. Until patched, do not pass untrusted YAML into load_from_yaml(); restrict YAML ingest to trusted sources. Rebuild and redeploy containers or images that vendor docling-core.

How to confirm the fix worked

Confirm docling-core is 2.48.4 or later, or that PyYAML is 5.4 or later, via package metadata, lockfiles, and MinimOS apk inventories. Verify the DoclingDocument YAML path no longer uses yaml.FullLoader. SCA should flag the combination of docling-core 2.21.0–2.48.3 and PyYAML < 5.4 as still exposed. After upgrade, regression-test legitimate YAML document loads and confirm YAML with non-standard constructor tags is rejected rather than executed. Review application call sites so load_from_yaml is not still fed user-controlled files.

Typical attack path

1. Identify a service that loads YAML via docling_core.types.doc.DoclingDocument.load_from_yaml()
2. Fingerprint or infer docling-core 2.21.0–2.48.3 together with PyYAML earlier than 5.4
3. Submit untrusted YAML through a document-ingest, API, or file-processing interface
4. Cause FullLoader to deserialize unsafe YAML tags and execute code in the application process
5. Use that execution to steal data, alter processed documents, persist, or move laterally

How to detect it

No public exploit activity is reported and exploit maturity is none, so confirmed in-the-wild use is unlikely but not impossible 250 days after the 2026-01-22 publication. Review application, reverse-proxy, and upload logs for YAML files or API bodies processed by Docling. On hosts that ran vulnerable docling-core, inspect ingested YAML for Python constructor tags and correlate with unexpected process creation, script interpreters, or outbound connections from the Python document worker. Treat inventories showing docling-core 2.21.0–2.48.3 plus PyYAML < 5.4 as confirmed exposure. SIEM hunts should include yaml.FullLoader in traces or errors, failures or crashes during YAML load, and unusual children of document-conversion services. Preserve YAML accepted by load_from_yaml() for forensic review.

• !!python/object/apply
• !!python/object/new
• !!python/name:
• !!python/module:
• yaml.FullLoader
• DoclingDocument.load_from_yaml
• docling_core.types.doc

What your security team should do

• Patch first: upgrade docling-core to 2.48.4+ or PyYAML to 5.4+ (MinimOS linux-virt and linux-virt-doc to 6.12.47-r0) and redeploy document-processing services
• Inventory every service, container, and lockfile with docling-core 2.21.0–2.48.3 and record whether PyYAML is below 5.4—the dual condition is what makes RCE reachable
• Until patched, block or sandbox untrusted YAML ingest into load_from_yaml() and limit those endpoints to authenticated, trusted sources
• Hunt for YAML containing Python object constructor tags and for anomalous child processes of Python/Docling workers
• Add SCA or allow-list controls so future builds cannot pull docling-core < 2.48.4 with PyYAML < 5.4; keep watching EPSS even though current exploitation signal is low