CVE-2026-105748 is a medium-severity (CVSS 4.3) CWE-73 vulnerability in docling. A fix is available for docling — see the affected versions and patch details below.
Docling: Crafted DoclingDocument JSON embeds local image files into converted output
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-105748.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-105748 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
docling🐍docling-slimReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
docling accepts serialized DoclingDocument JSON as an input format (InputFormat.JSON_DOCLING, enabled by default). A crafted JSON file can set a picture's image uri to a local file path. When the converted document is exported with embedded images (ImageRefMode.EMBEDDED, the CLI default for Markdown and HTML), the referenced file is read and embedded as base64 in the output.
Details
docling/backend/json/docling_json_backend.py validates the JSON into a DoclingDocument without checking image references. The file is then read by docling-core:
DoclingDocument._with_embedded_picturesopensfile://and plain-path URIs with PIL.ImageRef.pil_imagechecksallow_image_file_uriforfile://URIs but not for plainPathvalues. docling's picture enrichment models load images through this property.
Only files that PIL can decode as an image are disclosed. Other files, such as text files or keys, fail to decode and are not embedded. The different error behaviour does reveal whether a path exists.
Impact
Disclosure of image files readable by the converting process (for example other users' uploads or page images in a shared service), and disclosure of whether a local path exists.
Proof of concept
from pathlib import Path
from docling_core.types.doc import DoclingDocument, ImageRef
from docling_core.types.doc.base import Size
doc = DoclingDocument(name="poc")
doc.add_picture(image=ImageRef(mimetype="image/png", dpi=72, size=Size(width=1, height=1),
uri=Path("/srv/uploads/other-user/scan.png")))
doc.save_as_json("poc.json")
docling poc.json --to md embeds the referenced PNG as base64 in poc.md.
Patches
Fixed in docling 2.131.0 by #4417. The Docling JSON backend now drops image references that point at local files (paths, file: URIs and any scheme other than data: and http(s)) and logs a warning. Callers that need to load local images from JSON they trust can opt in with DoclingJSONFormatOption(backend_options=DeclarativeBackendOptions(enable_local_fetch=True)); the CLI has no such option.
Code that loads untrusted JSON directly with docling-core (DoclingDocument.load_from_json) and exports it with embedded images is not covered by this fix; that part is tracked in docling-core.
Workarounds
Upgrade to 2.131.0. For older versions:
- Remove
InputFormat.JSON_DOCLINGfromallowed_formatswhen converting untrusted input. - Export with
ImageRefMode.PLACEHOLDERorImageRefMode.REFERENCEDinstead ofEMBEDDED.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | docling | ≥ 2.16.0&&< 2.131.0 | 2.131.0pip install --upgrade 'docling==2.131.0' |
| 🐍PyPI | docling-slim | ≥ 2.92.0&&< 2.131.0 | 2.131.0pip install --upgrade 'docling-slim==2.131.0' |
Affected Products
doclingdoclingDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for docling, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update docling to 2.131.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-105748 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A low impact information disclosure flaw was found in the Docling document conversion library, which Red Hat ships in Red Hat OpenShift AI (RHOAI) and Lightspeed Core container images. The InputFormat.JSON_DOCLING backend accepts serialized DoclingDocument JSON without rejecting picture image references that contain…
The upstream fix is available in docling 2.131.0, where the JSON_DOCLING backend drops image references that point at local files and logs a warning. For versions that cannot yet be upgraded, the upstream project documents these workarounds when processing untrusted input: remove InputFormat.JSON_DOCLING from the allowed_formats list so that serialized DoclingDocument JSON is not accepted, and export documents using ImageRefMode.PLACEHOLDER or ImageRefMode.REFERENCED instead of ImageRefMode.EMBEDDED so that referenced local files are not read and embedded into the output.Source: Red Hat security advisory for CVE-2026-105748 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-105748 in your dependencies?
Find it across PyPI, including transitive dependencies.