Vulnerability DatabaseCVE-2026-105750

CVE-2026-105750: 
Python vulnerability analysis and mitigation

Overview

CVE-2026-105750 is a file disclosure vulnerability in Docling, an open-source document processing library for the generative AI ecosystem. The flaw exists in the HTMLBackendOptions(render_page=True) feature, where HTMLDocumentBackend._get_browser_request_block_reason fails to enforce the enable_local_fetch setting, allowing crafted HTML documents to embed and expose arbitrary local text files via browser-rendered page images. Affected versions are docling >= 2.82.0 and < 2.118.1, and docling-slim >= 2.92.0 and < 2.118.1. The vulnerability was published on September 28, 2026, and carries a CVSS v3.1 base score of 5.9 (Medium) (Github Advisory).

Technical details

The root cause is an incorrect authorization check (CWE-863) in HTMLDocumentBackend._get_browser_request_block_reason, which in affected versions unconditionally allowed file: URL schemes before evaluating any configuration options, effectively bypassing the enable_local_fetch guard (CWE-552, CWE-918). When render_page=True is set and Playwright is installed, Docling launches a headless Chromium browser to render HTML documents; because file: URLs were not blocked, a crafted HTML file passed as a filesystem Path could use HTML elements (e.g., <iframe> or <object>) to embed arbitrary local text files, whose contents would then appear in the rendered page image returned as part of the DoclingDocument. Versions 2.82.0–2.90.x performed no request filtering in render mode at all; from 2.91.0, JavaScript was disabled, making disclosure passive and limited to what Chromium renders visibly in the viewport. Stream inputs are not affected because they are loaded via page.set_content() into an opaque origin, from which Chromium does not load file:// subresources (Github Advisory, Fix PR).

Impact

Successful exploitation allows an unauthenticated attacker who can submit HTML documents for conversion to read arbitrary local text files accessible to the conversion process — including .env files, credential files, SSH keys, or other users' documents on a shared host — by embedding them in a crafted HTML document and retrieving the rendered page image. The impact is limited to confidentiality (no integrity or availability impact), and exploitation requires the specific combination of render_page=True, Playwright installed, and untrusted HTML passed as a filesystem Path. On multi-tenant or shared document processing platforms, this could enable cross-user data exposure and credential theft (Github Advisory).

Exploitability

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is 0.0, reflecting a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a high-complexity attack scenario: the attacker must be able to supply a crafted HTML file as a filesystem path to a Docling instance configured with render_page=True and Playwright installed, which is a non-default configuration.

Exploitation steps

  1. Identify a vulnerable target: Locate an application or service using Docling versions 2.82.0–2.118.0 (or docling-slim 2.92.0–2.118.0) that processes HTML documents with HTMLBackendOptions(render_page=True) and has Playwright installed.
  2. Craft a malicious HTML file: Create an HTML document that embeds a target local file using an HTML element such as <iframe src="file:///etc/passwd"> or <object data="file:///home/user/.env">, designed to render the file's contents visibly within the page viewport.
  3. Submit the HTML as a filesystem Path: Provide the crafted HTML file to the vulnerable Docling instance as a filesystem Path object (not a stream), triggering the HTMLDocumentBackend to load it via a file:// URL in the headless Chromium browser.
  4. Retrieve the rendered page image: The headless browser renders the page, embedding the contents of the targeted local file in the viewport. The rendered image is attached to the returned DoclingDocument object.
  5. Extract the disclosed data: Retrieve the page image from the DoclingDocument and read the embedded local file contents from the rendered image, potentially using OCR if needed (Github Advisory, Fix PR).

Indicators of compromise

  • File System: Unexpected or suspicious HTML files submitted to the document processing pipeline containing file:// URI references in <iframe>, <object>, <embed>, or <img> tags pointing to sensitive local paths (e.g., /etc/passwd, ~/.env, ~/.ssh/id_rsa).
  • Logs: Application logs showing Docling processing HTML files as filesystem Path inputs with render_page=True enabled; Playwright/Chromium browser logs recording file:// URL requests to paths outside the source document's directory.
  • Process: Headless Chromium processes (chromium, chrome) spawned by the Docling service accessing sensitive file paths outside the expected document directory.
  • Network: If the application returns or transmits rendered page images externally, unusual outbound data transfers containing rendered images with embedded text content from local system files.

Mitigation and workarounds

Upgrade to Docling version 2.118.1 or later, which fixes the issue by blocking file: URL requests in render mode unless enable_local_fetch=True is explicitly set, and confining allowed file sub-resources to the source document's directory (Docling Release). If immediate patching is not possible, the following workarounds apply: (1) avoid using render_page=True when processing untrusted HTML documents; (2) pass HTML input as a stream rather than a filesystem Path, as stream inputs use an opaque origin and are not affected; or (3) uninstall Playwright if browser-based rendering is not required. The default configuration (render_page=False), the Docling CLI, docling-serve, and non-rendering backends (EPUB, Markdown, XBRL, email) are not affected and require no action (Github Advisory).

Community reactions

The vulnerability was reported by researchers @priyankn and @DavidCarliez and was published as a GitHub Security Advisory (GHSA-q43m-vhcp-mhvm) by the Docling maintainer dolfim-ibm on September 28, 2026. The fix was reviewed and approved by multiple Docling core maintainers (PeterStaar-IBM, dolfim-ibm) and merged promptly (Fix PR). No significant broader media coverage or notable community controversy has been identified beyond standard vulnerability database aggregation.

Additional resources


Source: This report was generated using AI

Related Python vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

GHSA-v2f8-6655-7grjCRITICAL10
  • Python logoPython
  • vibe-trading-ai
NoYesOct 02, 2026
CVE-2026-105782HIGH7.5
  • Python logoPython
  • scrapy
NoYesOct 06, 2026
GHSA-v853-p72q-4cfwHIGH7.5
  • Python logoPython
  • quart
NoYesOct 05, 2026
CVE-2026-105751MEDIUM6.9
  • Python logoPython
  • docling
NoYesOct 05, 2026
CVE-2026-105750MEDIUM5.9
  • Python logoPython
  • docling
NoYesOct 05, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management