Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.82.0 until 2.118.1, HTMLBackendOptions(render_page=True) permits file URLs because HTMLDocumentBackend._get_browser_request_block_reason does not enforce the enable_local_fetch setting or confine local requests to the source document directory. Crafted path-backed HTML can embed a readable local text file in a browser-rendered page image when Playwright is installed. Only filesystem Path inputs are affected because stream inputs use an opaque origin, and the default configuration, command-line interface, docling-serve, and non-rendering backends are not affected. This issue is fixed in 2.118.1.

Affected: PyPI: docling, PyPI: docling-slim

### 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…