CVE-2026-105750 is a Medium severity flaw in Docling, the document conversion library. From 2.82.0 until 2.118.1, HTML rendering with render_page enabled allows file URLs and ignores the enable_local_fetch setting, so crafted HTML can show a local text file in the page image. Upgrade to 2.118.1.
What's affected
- Package: docling (pip), from 2.82.0 until 2.118.1.
- Package: docling-slim (pip), from 2.92.0 until 2.118.1, per the advisory.
- Fixed: 2.118.1.
- Condition: HTMLBackendOptions with render_page set to true, Playwright installed, and a filesystem Path as the input.
- Not affected: stream inputs, which use an opaque origin, according to the record.
The record scores this 5.9 Medium and the advisory calls it Moderate, so the two agree. The advisory adds that versions 2.82.0 to 2.90.x did no request filtering in render mode at all, and that from 2.91.0 the browser runs with JavaScript disabled, so disclosure is passive.
How to check if you're exposed
Docling is a Python package, and it also ships as docling-slim, so check both.
pip show docling docling-slim
pip freeze | grep -i docling
grep -ri "docling" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null
Check services that convert uploaded documents, notebooks, batch jobs and container images. Then check how Docling is configured, because every Docling advisory in this series depends on a specific option or file type, as described above.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan reads a manifest or lockfile and shows which packages carry known CVEs, including this one. Nothing is installed and nothing leaves your browser session beyond the scan itself.
Search for the render option and the browser dependency.
grep -rn "render_page" .
pip show playwright
If render_page is never set to true, or Playwright is not installed, the browser rendering path is not in use. If you do render HTML pages from untrusted sources by path, upgrade now.
What to do now
- Upgrade docling and docling-slim to 2.118.1 or later.
- Convert HTML from untrusted sources as streams rather than as paths where you can, since the record says stream inputs are not affected.
- Leave enable_local_fetch off unless you truly need local resources, and understand that fixed versions confine local fetches to the source folder.
- Run the render step in a container that holds no sensitive files.
- Review stored page images from earlier conversions for unexpected content.
- Re-scan your lockfiles after the update.
Why it matters
The record lists CWE-863, incorrect authorization, and CWE-552, files or directories accessible to external parties. The request filter in render mode allowed file URLs without reading the local fetch setting, so the option that is meant to forbid local access did nothing in this mode.
The result is limited by how the browser works. With JavaScript off, an attacker cannot script an upload of the file. Only what the browser draws inside the page viewport ends up in the page image. That is still enough to leak a readable text file such as a configuration file into a document that someone else may see.
The record does not list this CVE as exploited in the wild. It is a good illustration of settings that exist but are not enforced on every code path. The pull request changes render mode so it blocks other local file requests unless the option is enabled.
Quick check
Which inputs are affected?
Only filesystem Path inputs. The record says stream inputs use an opaque origin and are not affected.
What does the fix do?
Per the pull request, render mode always allows the main local HTML document, blocks other local file requests unless enable_local_fetch is set, and then confines them to the source folder.
Sources
- Docling GitHub security advisory GHSA-q43m-vhcp-mhvm
- Docling release v2.118.1
- Docling pull request 3948
Last reviewed: 18 October 2026.
