CVE-2026-105751: 
Python vulnerability analysis and mitigation

CVE-2026-105751 is an arbitrary local file read vulnerability in Docling's OpenDocument (ODF) backend, classified as a path traversal flaw (CWE-22). It affects docling versions >= 2.107.0 and < 2.120.3, introduced by commit e2afe381 on 2026-06-24 and first released in v2.107.0. The vulnerability was reported by researcher arexgodofwar, published to the GitHub Advisory Database on August 24, 2026, and disclosed publicly on October 5, 2026. It carries a CVSS v4.0 base score of 6.9 (Medium) and a CVSS v3.1 base score of 3.3 (Low) (Github Advisory, Feedly).

The root cause is in docling/backend/opendocument_backend.py, specifically the _image_ref_from_odf_image function, which reads the xlink:href attribute of a draw:image element directly from content.xml and uses it as a filesystem path when the referenced part is not found inside the document archive (CWE-22). The vulnerable fallback code calls Path(image_url).read_bytes() without any scheme check, extraction-directory confinement, or consultation of the enable_local_fetch/enable_remote_fetch controls enforced by all other Docling backends (HTML, Markdown, EPUB, XBRL) via ImageResourceLoader. The only input filter, _odf_image_can_be_bitmap, previously allowed empty-suffix paths (e.g., /etc/passwd, /proc/self/environ) in addition to common image extensions, making most Unix system files reachable. A proof-of-concept trigger is a 452-byte .odt archive containing only mimetype and content.xml with a crafted xlink:href pointing to an absolute filesystem path (Github Advisory, Fix PR).

Successful exploitation allows an attacker who can supply a malicious ODF document for processing to read arbitrary local files accessible to the Docling process. Files that Pillow can decode as images are fully disclosed — their bytes are embedded verbatim and base64-encoded in the resulting DoclingDocument's HTML, Markdown, and JSON exports. Additionally, the vulnerability functions as a silent file-existence oracle: both existing and non-existing paths can be distinguished by side-channel while conversion reports success in both cases, enabling filesystem enumeration. There is no integrity or availability impact, but confidentiality is significantly affected, particularly in deployments processing sensitive documents or operating in air-gapped environments (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date (Feedly). The vulnerability requires user interaction (a user or service must process the malicious document), but no authentication or special privileges are needed. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The advisory notes that if exploited via docling-serve (which binds to 0.0.0.0 with no API key by default), the attack could be fully remote and unauthenticated, potentially raising the effective severity (Github Advisory).

1. Craft malicious ODT archive: Create a minimal .odt ZIP archive (as small as 452 bytes) containing only two entries: mimetype (stored uncompressed, containing application/vnd.oasis.opendocument.text) and content.xml with a draw:image element whose xlink:href attribute points to a target absolute filesystem path (e.g., /etc/passwd for extension-less files, or /tmp/sensitive.png for image-decodable files).
2. Deliver the document: Submit the crafted .odt file to a system running a vulnerable Docling instance (versions 2.107.0–2.117.0). This could be via a file upload interface, an API endpoint accepting ODF documents, or by convincing a user to process the file locally.
3. Trigger conversion: The victim system processes the document using DocumentConverter().convert(Path('trigger.odt')). The ODF backend attempts to locate the image part inside the archive, fails, and falls back to reading the xlink:href value directly from the filesystem via Path(image_url).read_bytes().
4. Retrieve disclosed content: If the target file is decodable by Pillow (e.g., a PNG or JPEG), its full contents are embedded base64-encoded in the conversion output (HTML, Markdown, or JSON export). For extension-less paths like /etc/passwd, the file is opened and read but not embedded; the attacker can distinguish existence from non-existence by observing conversion behavior.
5. Enumerate filesystem (optional): Repeat with different absolute paths to silently enumerate file existence across the host filesystem, leveraging the oracle behavior where conversion always reports success regardless of whether the file exists (Github Advisory, Fix PR).

• File System: Unexpected .odt, .ods, or .odp files submitted for processing that contain no embedded image parts but reference absolute filesystem paths in content.xml (e.g., xlink:href="/etc/passwd" or xlink:href="/tmp/canary.png").
• Logs: Docling conversion logs showing successful processing of ODF documents that produce no picture items despite containing draw:image elements; audit hook events (open syscall) for system files (e.g., /etc/passwd, /proc/self/environ) triggered by the Docling process.
• Network: If using docling-serve, unexpected POST requests submitting small ODF files (< 1 KB) with no embedded image data to the conversion endpoint; outbound data in conversion responses containing base64-encoded content not originating from the submitted document.
• Process: The Docling Python process opening files outside its working directory or document extraction path, particularly system files or files in unrelated directories, observable via strace, auditd, or Python's sys.addaudithook (Github Advisory, Fix PR).

Upgrade docling to version 2.120.3 or later, which resolves the issue by routing all external xlink:href values through ImageResourceLoader (governed by enable_remote_fetch and enable_local_fetch, both defaulting to False) and removing the empty-suffix case from the bitmap allow-list (Docling Release, Fix PR). If immediate patching is not possible, restrict document processing to trusted sources only and apply OS-level file access controls (e.g., run the Docling process under a restricted user account with minimal filesystem permissions) to limit the scope of potential file disclosure (Feedly).

The vulnerability was responsibly disclosed by researcher arexgodofwar and acknowledged by the Docling maintainers (IBM), who merged the fix within one day of the pull request submission (PR #4015 opened August 17, merged August 18, 2026). The advisory notes similarity in class and impact to two previously rated High vulnerabilities in the docling ecosystem: CVE-2026-44019 and CVE-2026-44023, both involving unsafe file reference handling. Red Hat tracked the issue via Bugzilla and published a CVE advisory, indicating downstream awareness (Github Advisory, Red Hat).