CVE-2026-105750: Local File Disclosure in Docling via Permissive HTML Rendering Requests Filter

Docling and Docling-Slim are specialized Python libraries used in modern data-engineering pipelines to parse, structure, and convert document formats such as PDFs, Office files, and HTML into structured JSON or Markdown. To support downstream generative AI pipelines and Retrieval-Augmented Generation (RAG) tasks, the library offers a visual page-rendering mode using a headless browser. When configured with HTMLBackendOptions(render_page=True) and with Playwright installed, the backend spawns a browser context to capture precise layout structures, visual elements, and embedded styling.

To restrict the browser context from accessing unauthorized network or filesystem assets, the application implements custom request filtering. The core of this mechanism resides within the HTMLDocumentBackend._get_browser_request_block_reason method, which dynamically inspects each URI request initiated by the browser during parsing. In vulnerable versions starting from 2.82.0 up to but not including 2.118.1, this filter permitted local directory and scheme access without sufficient constraints.

Specifically, the implementation unconditionally approved requests utilizing the file:// scheme, allowing the browser engine to query any absolute path on the host filesystem that was accessible to the running process. When a document is processed from a local filesystem path, this gap allows malicious HTML documents to load, render, and exfiltrate highly sensitive files, such as Unix configurations or application database secrets, directly into the document layout structure.

The root cause of CVE-2026-105750 lies in a flawed authorization policy in the request interceptor of the HTML document rendering backend. When Playwright is instructed to render an HTML page, it registers a route handler to inspect every network and filesystem sub-request. The HTMLDocumentBackend._get_browser_request_block_reason method is invoked to evaluate if a request should be blocked based on security configurations.

In affected versions, the filter logic parsed the target URL and extracted the lowercase URI scheme. If the parsed scheme matched file, data, about, or blob, the function immediately returned None, which signifies that there is no block reason. This logic failed to account for the risk of local file extraction when rendering an untrusted local HTML document.

Because the browser executed within the server's context, any resource references using the file:// scheme were evaluated from the server's perspective. If an attacker could force the pipeline to process an HTML file via a filesystem Path input, the browser was granted full access to read local file paths via standard HTML embedding tags such as iframe, object, or link.

Crucially, this vulnerability is only exploitable when the file is parsed using a filesystem Path input rather than a memory stream. If a stream-based input is used, the browser executes the rendering process within an opaque origin context, which automatically restricts local file access due to standard browser-level sandbox policies. However, when a Path is used, the browser context inherits file system privileges relative to the document's location.

To understand the vulnerability and its remediation, we must examine the changes made to docling/backend/html_backend.py in the fix commit 1612b8875b0937447ce3122536fb5360a7102a0a.

Prior to the patch, the block reasoning logic was highly permissive towards the file scheme:

def _get_browser_request_block_reason(self, request_url: str) -> Optional[str]:
    parsed = urlparse(request_url)
    scheme = (parsed.scheme or "").lower()
    # VULNERABLE: Unconditionally permitting file:// scheme requests
    if scheme in {"file", "data", "about", "blob"}:
        return None
 
    if ImageResourceLoader.is_remote_url(request_url):
        # ... remote validation checks ...

The patch resolved this by introducing two helpers: _get_browser_local_base_path and _is_allowed_browser_file_request. Together, they enforce strict confinement policies:

    def _get_browser_local_base_path(self) -> Optional[Path]:
        if isinstance(self.path_or_stream, Path):
            return self.path_or_stream.resolve()
 
        if self.base_path and ImageResourceLoader.is_local_path(self.base_path):
            return Path(self.base_path).resolve()
 
        return None
 
    def _is_allowed_browser_file_request(self, request_url: str) -> bool:
        local_base_path = self._get_browser_local_base_path()
        # Permit loading of the source document itself
        if local_base_path is not None and request_url == local_base_path.as_uri():
            return True
 
        # Restrict loading of sub-resources unless explicitly allowed and within path bounds
        if not self.options.enable_local_fetch or local_base_path is None:
            return False
 
        # Normalize path traversing patterns to prevent directory escape
        requested_path = Path(url2pathname(urlparse(request_url).path)).resolve()
        return requested_path.is_relative_to(local_base_path.parent)

With these changes, the modified filtering logic checks file requests against the allowed directory boundaries. It restricts file requests to the parent directory of the source HTML document being parsed. This prevents arbitrary directory traversal attacks using parent sequences or symbolic links.

Exploiting this vulnerability requires three prerequisites: the target system must have the Playwright dependency installed, the parsing pipeline must configure HTMLBackendOptions(render_page=True), and the application must receive and parse an HTML file path rather than a memory stream.

An attacker can construct a payload HTML document containing tags that reference target host files. For instance, embedding an <iframe> targeting file:///etc/passwd or /etc/resolv.conf forces the headless browser to retrieve these files during the document layout phase.

When the Docling pipeline processes this document, Playwright executes the parsing request, retrieves the targeted file, and renders its contents inside the output document layout structure. Because Docling extracts text content and layout structures from the rendered view, the contents of the target file are incorporated into the final processed output object.

<!DOCTYPE html>
<html>
<head>
    <title>Exploit Payload</title>
</head>
<body>
    <!-- Embed sensitive configuration file -->
    <iframe src="file:///etc/passwd" width="100%" height="600px"></iframe>
</body>
</html>

If the application returns the parsed output (such as converted Markdown or text layouts) to the user, the attacker can view the exact contents of the host file. This can lead to information disclosure of service credentials, environment variables, or critical system structures.

The impact of CVE-2026-105750 is classified as high confidentiality loss with a CVSS base score of 5.9. In typical server environments where Docling processes user-supplied documents, such as automated RAG pipelines, chatbots, or document analysis services, this flaw can expose sensitive local configurations.

If an application runs with elevated privileges, an attacker can extract system configuration files, cloud instance credentials (such as local metadata server keys), internal network details, and SSH keys. This data can facilitate lateral movement within the network or cloud environment.

Furthermore, because this flaw operates at the document layout engine layer, traditional input validation controls that only inspect raw text strings may fail to detect the visual file injection. The vulnerability does not affect system integrity or availability, as the execution bounds are restricted to read operations.

To address this vulnerability, administrators and developers must upgrade the docling and docling-slim packages to version 2.118.1 or later. This version enforces path-confinement policies and disables local file loading by default.

pip install --upgrade docling docling-slim

If upgrading is not immediately possible, implement the following workarounds to reduce risk:

1. Ensure that the enable_local_fetch option within HTMLBackendOptions is configured to False. This is the default setting and prevents the browser from making local filesystem requests during rendering.

2. Avoid using the HTML rendering page option (render_page=True) when processing untrusted HTML files. Using non-rendering parser backends avoids initializing Playwright contexts, neutralizing the attack vector.

3. Configure the parsing pipeline to receive inputs as memory streams (e.g., BytesIO) rather than local file system paths. Processing inputs as streams forces Playwright to operate within an opaque origin context, which prevents the loading of local file resources.