CVE-2026-44019: 
Python vulnerability analysis and mitigation

CVE-2026-44019 is a vulnerability in docling-core (a Python document processing library) involving insufficient validation of image reference URIs, enabling local file disclosure and denial of service. It affects versions >= 2.5.0, < 2.74.1 of the docling-core pip package. The vulnerability was published on June 2, 2026, by maintainer dolfim-ibm, and added to the GitHub Advisory Database on June 3, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Security Advisory).

The root cause is twofold: the library fails to restrict user-controlled image reference URIs (CWE-73: External Control of File Name or Path) and imposes no decoded-size limit on inline data: image content (CWE-400: Uncontrolled Resource Consumption). When an application built on docling-core processes untrusted document input containing image references, an attacker can supply a file:// URI pointing to any local file readable by the process, or embed an arbitrarily large data: payload to exhaust system memory. Exploitation requires user interaction — specifically, a user or automated pipeline must process a maliciously crafted document — but no authentication or special privileges are needed (GitHub Advisory, Security Advisory).

Successful exploitation can result in two distinct impacts: high confidentiality loss through unauthorized access to local files readable by the application process (e.g., configuration files, credentials, or sensitive data), and high availability impact through memory exhaustion caused by processing oversized inline data: image payloads. Integrity is not directly affected. Applications that ingest untrusted documents — such as AI document pipelines, document conversion services, or web-facing upload processors — are most at risk, and file disclosure could facilitate lateral movement if sensitive credentials or internal configurations are exposed (GitHub Advisory).

1. Identify a target application: Locate an application that uses docling-core versions >= 2.5.0, < 2.74.1 and accepts untrusted document input containing image references (e.g., a document conversion API or AI pipeline).
2. Craft a malicious document: Create a document (e.g., a Docling-format JSON or supported input format) that includes an image reference using a file:// URI pointing to a sensitive local file, such as file:///etc/passwd or file:///app/config/secrets.env.
3. Submit the document: Upload or submit the crafted document to the target application, triggering docling-core to process the image reference without URI scheme validation.
4. Retrieve disclosed file contents: The application reads and processes the referenced local file as image data; depending on how the application surfaces output, the file contents may be returned in the response, logged, or embedded in processed output.
5. Alternatively, trigger DoS: Craft a document with an inline data: image URI containing an extremely large base64-encoded payload (no size limit is enforced), causing the process to allocate excessive memory and potentially crash or become unresponsive (GitHub Advisory, Security Advisory).

• Network: Unexpected outbound connections or large response payloads from document processing services; HTTP requests submitting documents with file:// or oversized data: image URIs in the body.
• Logs: Application logs showing image URI resolution attempts against local filesystem paths (e.g., /etc/, /var/, /app/); memory allocation errors or OOM (out-of-memory) kill events in system logs coinciding with document processing requests.
• Process: Sudden spikes in memory consumption by the docling-core processing worker; process crashes or restarts of document ingestion services.
• File System: No direct file system artifacts expected from the attacker side, but audit logs may show unexpected read access to sensitive files by the application process user.

Upgrade docling-core to version 2.74.1 or later, which blocks local file:// URIs by default and enforces a decoded-size limit on inline data: image content (Release v2.74.1). If immediate upgrade is not possible, apply the following workarounds: reject file: and data: image references from any untrusted input at the application layer; restrict image sources to an approved allowlist of local or remote URIs; and apply input size and memory limits to document processing workers (Security Advisory).