Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

Docling: `enable_local_fetch` is not enforced in HTML browser-rendering modeGHSA-q43m-vhcp-mhvm

MEDIUMFix: docling-project/docling#3948

GHSA-q43m-vhcp-mhvm is a medium-severity (CVSS 5.9) CWE-552 vulnerability in docling. A fix is available for docling — see the affected versions and patch details below.

Also known asCVE-2026-105750PYSEC-2026-4196
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 8, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-q43m-vhcp-mhvm.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs21th percentile — riskier than 21% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-q43m-vhcp-mhvm by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 384,534 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected
🐍docling🐍docling-slim

Real-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

When the HTML backend renders pages in a headless browser (HTMLBackendOptions(render_page=True)), the enable_local_fetch option is not enforced. A crafted HTML file can embed an arbitrary local file (for example with <iframe src="file:///...">), and that file's contents appear in the page image attached to the returned DoclingDocument.

Details

In render mode, Playwright requests are filtered by HTMLDocumentBackend._get_browser_request_block_reason. In affected versions, this check allowed file: URLs unconditionally, before reading any option. As a result:

  • enable_local_fetch=False did not block local file access, and
  • even with enable_local_fetch=True, file access was not limited to the source document's directory, unlike the non-render path (ImageResourceLoader), which rejects absolute paths and path traversal.

Versions 2.82.0–2.90.x did no request filtering in render mode at all.

The browser runs with JavaScript disabled (from 2.91.0), so disclosure is passive: only what Chromium renders visibly inside the page viewport ends up in the page image.

Only Path inputs are affected. They are loaded through a file:// URL. Stream inputs are loaded with page.set_content() into an opaque origin, from which Chromium does not load file:// subresources.

Impact

An attacker who can submit HTML for conversion can read any text file the conversion process can read (for example .env files, credential files, or other users' documents on a shared host) by having it rendered into the page image.

Only applications that meet all of these conditions are affected:

  • they set HTMLBackendOptions(render_page=True) in Python,
  • they have the optional playwright dependency installed, and
  • they pass untrusted HTML as a filesystem Path.

The following are not affected: the default configuration (render_page=False), the docling CLI, docling-serve, and the EPUB, Markdown, XBRL and email backends.

Patches

Fixed in 2.118.1 (#3948). In render mode, file: requests are now blocked unless enable_local_fetch=True, and allowed requests are limited to the source document's directory.

Workarounds

If you can't upgrade, don't use render_page=True on untrusted HTML, or pass the input as a stream instead of a Path.

Credits

Reported by @priyankn.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIdocling≥ 2.82.0&&< 2.118.12.118.1pip install --upgrade 'docling==2.118.1'
🐍PyPIdocling-slim≥ 2.92.0&&< 2.118.12.118.1pip install --upgrade 'docling-slim==2.118.1'

Affected Products

1 product · 1 configurations
Application
doclingdocling
≥ 2.82.0 && < 2.118.1
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    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.

  2. Fix

    Update docling to 2.118.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q43m-vhcp-mhvm is resolved across your whole dependency graph.

  3. Workarounds

    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Frequently Asked Questions

### Summary When the HTML backend renders pages in a headless browser (`HTMLBackendOptions(render_page=True)`), the `enable_local_fetch` option is not enforced. A crafted HTML file can embed an arbitrary local file (for example with `<iframe src="file:///...">`), and that file's contents appear in the page image attached to the returned `DoclingDocument`. ### Details In render mode, Playwright requests are filtered by `HTMLDocumentBackend._get_browser_request_block_reason`. In affected versions, this check allowed `file:` URLs unconditionally, before reading any option. As a result: - `ena
O3 Security · Impact-Aware SCA

Is GHSA-q43m-vhcp-mhvm in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
Docling: `enable_local_fetch` is not enforced in HTML…