Lack of data validation - Path Traversal In docling
Description
Docling has arbitrary file read/write (and command execution when shell-escape is enabled) when rendering untrusted TikZ with the opt-in Tectonic engine
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};...
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.
Mitigation
Update Impact
Minimal update. May introduce new vulnerabilities or breaking changes.
Ecosystem | Component | Affected version | Patched versions |
|---|---|---|---|
pypi | 2.132.0 | ||
pypi | 2.132.0 |
Aliases
References