Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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/imageresourceloader.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 enableremotefetch=True and fetchimages=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…
Recommended action: Upgrade to 2.132.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When remote fetching is enabled (enableremotefetch=True, together with fetchimages=True or HTML renderpage=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 (renderpage=True), requests made by the page are allowed for any http(s) URL without an IP check. Details - validateurlsafety in docling/backend/utils/imageresourceloader.py calls socket.gethostbyname(), which returns one IPv4 address. It checks…
Recommended action: Upgrade to 2.132.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the LaTeX backend is configured to render TikZ pictures with the Tectonic engine (LatexBackendOptions(tikzengine="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 tikzengineallowshellescape=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. resolvelocaldependency 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…
Recommended action: Upgrade to 2.132.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
docling accepts serialized DoclingDocument JSON as an input format (InputFormat.JSONDOCLING, 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/doclingjsonbackend.py validates the JSON into a DoclingDocument without checking image references. The file is then read by docling-core: - DoclingDocument.withembeddedpictures opens file:// and plain-path URIs with PIL. - ImageRef.pilimage checks allowimagefileuri 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…
Recommended action: Upgrade to 2.131.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/htmlbackend.py (getcellspans) parses span attributes with no upper limit. The cell-filling loop then iterates rowspan × colspan times. - docling/backend/jatsbackend.py and docling/backend/boxnotebackend.py fill their tables the same way. - The OpenDocument spreadsheet path scans the declared span range. - Export (for example exporttomarkdown()) materialises the full grid through TableData.grid in docling-core. documenttimeout does not bound this. It is checked between pipeline stages, and these backends convert the whole document in a single call. maxfilesize and maxnumpages do not help because the payload is tiny. Measured…
Recommended action: Upgrade to 2.131.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
allowexternalplugins=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 loadsetuptoolsentrypoints(), 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/basefactory.py, loadfromplugins() loads all entry points first and applies the allowexternalplugins 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…
Recommended action: Upgrade to 2.131.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 maxmembercount 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/metsgbsbackend.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 allowedformats is applied, so the allocation happens even when METS-GBS is not an allowed format. This check was introduced by the fix for…
Recommended action: Upgrade to 2.131.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the HTML backend renders pages in a headless browser (HTMLBackendOptions(renderpage=True)), the enablelocalfetch option is not enforced. A crafted HTML file can embed an arbitrary local file (for example with <iframe src="file:///..."), and that file's contents appear in the page image attached to the returned DoclingDocument. Details In render mode, Playwright requests are filtered by HTMLDocumentBackend.getbrowserrequestblockreason. In affected versions, this check allowed file: URLs unconditionally, before reading any option. As a result: - enablelocalfetch=False did not block local file access, and - even with enablelocalfetch=True, file access was not limited to the source document's directory, unlike the non-render path (ImageResourceLoader), which rejects absolute paths and path traversal. Versions 2.82.0–2.90.x did no request filtering in render mode at all. The browser runs with JavaScript disabled (from 2.91.0), so disclosure is passive: only what Chromium…
Recommended action: Upgrade to 2.118.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ODF backend resolves the xlink:href of a draw:image element as a filesystem path whenever the referenced part is not found inside the document archive. The value comes straight from content.xml, so it is document content, and it is used with no scheme check, no confinement to the extraction directory, and without consulting the enablelocalfetch / enableremotefetch controls that the other backends use for exactly this decision. Converting a crafted .odt therefore causes Docling to open an attacker-named absolute path on the converting host. Where the target decodes as an image, its complete contents are embedded in the resulting DoclingDocument and appear in the HTML, Markdown and JSON exports. Both the read and the disclosure are confirmed by execution. The trigger is a 452-byte archive containing two entries. Affected component docling/backend/opendocumentbackend.py, in imagereffromodfimage: odfimagehref returns the xlink:href attribute. The in-archive lookup is…
Recommended action: Upgrade to 2.120.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The HTML backend did not perform sufficient validation during resource handling: - Accepted file:// URIs enabling local file system access when enablelocalfetch=True - Path resolution allowed traversal outside intended directories via ../ sequences and absolute paths - Did not block internal network resources under enableremotefetch=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 enablelocalfetch=True (default: False) and containment within configured basepath 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…
Recommended action: Upgrade to 2.94.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The LaTeX backend's handling of \includegraphics, \input, and \include commands lacked path containment validation. Attackers could craft malicious LaTeX documents with path traversal sequences (e.g., ../../../etc/passwd) to: - Read arbitrary files from the file system accessible to the process - Include sensitive files in the converted document output - Potentially access configuration files, credentials, or other sensitive data Patches Fixed in version 2.91.0. The fix implements strict path validation using Path.resolve().isrelativeto() to ensure all resolved paths remain within the base document directory. Attempts to traverse outside the base directory are logged and blocked. Workarounds Avoid processing untrusted LaTeX documents. If processing is necessary, run in a sandboxed environment with restricted file system access. References - Fix release: v2.91.0
Recommended action: Upgrade to 2.91.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 - 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. Patches Fixed in version 2.74.0. The parser now uses defusedxml.sax.makeparser() with secure configuration that blocks external entity resolution (featureexternalges=False, featureexternalpes=False) while allowing DTD declarations required by USPTO files. This prevents XXE attacks while maintaining compatibility with the USPTO XML format. Workarounds Avoid processing USPTO patent XML files from untrusted sources. Implement resource limits (memory, CPU time) when…
Recommended action: Upgrade to 2.74.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The METS-GBS backend's XML parsing and the input document format detection lacked security controls, enabling: - XML External Entity (XXE) attacks to read local files or cause denial of service - Decompression bombs (zip bombs) to exhaust memory and disk space - Unbounded archive extraction consuming system resources An attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes. Patches Fixed in version 2.91.0. The fix implements: - Secure XML parsing with resolveentities=False, loaddtd=False, and nonetwork=True - Configurable limits: 300 MB total extraction size, 10 MB per file, 1000 member count - Cumulative size tracking across all extractions - Early termination when limits are exceeded - Secure format detection of METS-GBS tar archives with detectmetsgbs() method: maximum file size (10 MB per file), maximum member count (1000 members), and exception handling to gracefully fail…
Recommended action: Upgrade to 2.91.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions = 2.82.0, < 2.91.0, if the HTML backend was explicitly configured for rendering (rendering option by default deactivated), then the Playwright-based rendering feature could allow JavaScript execution and unrestricted network access when processing untrusted HTML documents. An attacker could craft malicious HTML that executes arbitrary JavaScript in the rendering context or makes unauthorized network requests to internal services, potentially leading to SSRF attacks, data exfiltration, or remote code execution in the rendering environment. Patches Fixed in version 2.91.0. The rendering context now explicitly disables JavaScript execution (javascriptenabled=False) and implements network isolation controls. When enableremotefetch is disabled, the browser operates in offline mode, preventing all network requests. Workarounds Refrain from using renderpage=True when processing untrusted HTML documents. References - Fix release: v2.91.0
Recommended action: Upgrade to 2.91.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions < 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 - Data corruption or system compromise Patches Fixed in version 2.91.0. The extraction process now validates each archive member path using os.path.realpath() to ensure it remains within the target directory, raising a SecurityError for any path traversal attempts. Workarounds Ensure model downloads occur over secure, authenticated channels. Use integrity verification (checksums) for downloaded models. Run the application with minimal file system permissions. References - Fix release: v2.91.0
Recommended action: Upgrade to 2.91.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.