Docling
Monthly
Local file disclosure in Docling allows crafted HTML to embed readable files from the host filesystem into the rendered page image. When an application explicitly sets HTMLBackendOptions(render_page=True), has the optional Playwright dependency installed, and passes untrusted HTML as a filesystem Path, the HTML backend's browser request filter fails to enforce the enable_local_fetch setting or confine file:// access to the source document's directory, so an <iframe src="file:///..."> can pull in .env files, credentials, or other users' documents that Chromium then renders visibly into the output image. Publicly available exploit code exists and the issue is fixed in 2.118.1; EPSS is low (0.30%, 21st percentile) and there is no indication of active exploitation, so real-world priority is comparatively low despite the 7.5 CVSS, because exploitation demands a specific non-default configuration and disclosure is passive, read-only, and limited to text content Chromium renders in the viewport.
Import-time code execution in Docling 2.27.0 through 2.131.0 lets any distribution already present in the same Python environment that registers an entry point in the 'docling' group run arbitrary code as soon as Docling's plugin factories initialize - even when allow_external_plugins is set to false, because the plugin manager imports every registered module before the namespace allow-list is applied and then misleadingly logs that the plugin was skipped. The assessed vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) confirms this is a local, supply-chain-style prerequisite: an attacker must first get a third-party or compromised package installed and registered, and Docling must then be started by a user, so there is no remote network exploitation path. No public exploit code or active exploitation is known at time of analysis (EPSS 0.11%, percentile 1%; CISA SSVC exploitation: none), and the vendor has shipped a fix in 2.131.0.
Docling 2.94.0 through 2.131.x allows an attacker-supplied LaTeX/TikZ document to read files accessible to the converter process and create or overwrite writable files when the caller has explicitly opted into Tectonic rendering via LatexBackendOptions(tikz_engine="tectonic"); enabling the additional tikz_engine_allow_shell_escape option escalates this to shell command execution through TeX. The default Docling configuration does not enable Tectonic rendering and is not affected, and exploitation further requires a victim or operator to feed the crafted document into the pipeline (UI:R), which is why the practical risk is conditional despite the high CVSS base score. Both docling and docling-slim are affected; the flaw is fully fixed in 2.132.0, EPSS is a low 0.30% (21st percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis.
Local file disclosure in Docling's OpenDocument backend (versions 2.107.0 through 2.120.3) allows an attacker-supplied ODF file to force the parser to read arbitrary filesystem paths. When a draw:image element's xlink:href references a part missing from the document archive, the vulnerable backend treats the href as a local filesystem path without a scheme check or extraction-directory confinement, then embeds Pillow-decodable files into the converted output; non-image paths still leak existence information through read success or failure. Exploitation requires a victim or automated pipeline to convert a malicious ODF document (UI:A) in an unauthenticated network-reachable context (PR:N), and no public exploit code or CISA KEV active-exploitation entry has been identified at time of analysis. Note that on affected versions this code path bypassed the enable_local_fetch setting that other Docling backends honor, so the read occurred regardless of that configuration. The vulnerability is fixed in 2.120.3.
Unbounded rowspan/colspan attribute handling in Docling 2.0.0 through 2.130.x lets a deliberately crafted document force sustained CPU consumption or multi-gigabyte memory allocation during table parsing, denying service to the process doing the conversion. Four document backends are affected - HTML, JATS, OpenDocument spreadsheet, and BoxNote - and the built-in document_timeout setting does not interrupt the single backend conversion call, so the usual safeguard against runaway parses is ineffective. The flaw is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H): unauthenticated from the network but requiring the target to ingest the malicious file, with availability as the sole impact. No public exploit code identified at time of analysis, and the vulnerability is fixed in 2.131.0.
Information disclosure in Docling (and the docling-slim distribution) versions 2.16.0 through 2.130.x lets an attacker embed local file paths or file: URIs inside a crafted DoclingDocument JSON that, when re-converted and enriched or exported with ImageRefMode.EMBEDDED, causes Docling to open and embed the referenced file's bytes into Markdown or HTML output. Per the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, score 4.3), no privileges are needed but the victim must actively load the malicious JSON, and exposure is constrained to files Pillow can decode as images, with differing decode behavior potentially revealing whether a path exists. There is no public exploit code identified at time of analysis and the issue is not listed in CISA KEV; the flaw is fixed in Docling 2.131.0.
Processing a crafted document with Docling (or the docling-slim distribution) versions 2.45.0 through 2.130.x can exhaust process memory: a small gzip-compressed tar archive that declares a very large number of empty members causes the full archive member list to be materialised before the configured max_member_count limit can stop processing. The flaw sits in METS-GBS format detection (docling/datamodel/document.py) and the METS-GBS backend (docling/backend/mets_gbs_backend.py), and because detection runs before the allowed_formats restriction is applied, an attacker does not need METS-GBS to be an enabled format - remote, unauthenticated delivery is possible per the CVSS vector (AV:N/PR:N), though a user or automated pipeline must actually submit the file (UI:R), and the resulting impact is limited to availability (A:L, CVSS 4.3) with no code execution or data disclosure. No public exploit code was identified at time of analysis and the issue is not recorded as actively exploited; a vendor fix is available in 2.131.0.
Docling 2.83.0 through 2.130.x ignores the enable_remote_services=False policy when OCR is configured with KserveV2OcrOptions, so page-image crops are still transmitted to the caller-configured KServe v2/Triton inference endpoint during PDF processing. The defect is a security-control bypass rather than attacker-driven exfiltration: the remote destination is chosen by the operator, the vulnerable code path is inert unless a second, non-default remote OCR engine is explicitly configured, and satisfying the assessed vector (AV:L/AC:H/PR:H) requires local access with high privileges. The assessed impact is confined to low-severity confidentiality exposure of processed page images, with no integrity, availability, or code-execution effect; no public exploit code and no CISA KEV entry were identified at time of analysis, and the flaw is fixed in 2.131.0.
Server-side request forgery in Docling 2.91.0 through 2.131.x lets an attacker-supplied document reach internal services whenever remote document fetching is explicitly enabled, because validate_url_safety in docling/backend/utils/image_resource_loader.py performs only a single IPv4 lookup before the HTTP client re-resolves and parses the original URL. The same trust gap applies to HTMLBackendOptions(render_page=True), which issues HTTP and HTTPS browser requests without validating their resolved destination, so exploitation also covers DNS rebinding, mixed public/internal address records, and backslash-authority parser disagreement. Exploitation is gated by non-default configuration (fetch_images=True with enable_remote_fetch=True, --html-image-fetch remote, or render_page=True), requires the attacker to supply a processed document and win a rebinding timing race, and exposure is limited to responses successfully decoded as images or passively captured in a page screenshot; CVSS 3.1 is 4.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N), no public exploit identified at time of analysis, and the issue is fixed in 2.132.0.
Docling's HTML backend forwards operator-configured HTTP headers - bearer tokens, API keys, cookies set via HTMLBackendOptions.headers - to every remote image URL named by an untrusted HTML document, including after a cross-origin redirect, leaking the caller's credentials to whoever authored the document. The flaw lives in docling/backend/utils/image_resource_loader.py in versions 2.95.0 through 2.131.x and is only reachable in a deliberately non-default configuration where both enable_remote_fetch and fetch_images are enabled and sensitive headers have been configured; the default configuration carries no exposure. Upstream scored it CVSS 3.7, while independent assessment rates the confidentiality impact as High given that live credentials are disclosed; no public exploit code has been identified at time of analysis, and the issue is fixed in 2.132.0.
Local file disclosure in Docling allows crafted HTML to embed readable files from the host filesystem into the rendered page image. When an application explicitly sets HTMLBackendOptions(render_page=True), has the optional Playwright dependency installed, and passes untrusted HTML as a filesystem Path, the HTML backend's browser request filter fails to enforce the enable_local_fetch setting or confine file:// access to the source document's directory, so an <iframe src="file:///..."> can pull in .env files, credentials, or other users' documents that Chromium then renders visibly into the output image. Publicly available exploit code exists and the issue is fixed in 2.118.1; EPSS is low (0.30%, 21st percentile) and there is no indication of active exploitation, so real-world priority is comparatively low despite the 7.5 CVSS, because exploitation demands a specific non-default configuration and disclosure is passive, read-only, and limited to text content Chromium renders in the viewport.
Import-time code execution in Docling 2.27.0 through 2.131.0 lets any distribution already present in the same Python environment that registers an entry point in the 'docling' group run arbitrary code as soon as Docling's plugin factories initialize - even when allow_external_plugins is set to false, because the plugin manager imports every registered module before the namespace allow-list is applied and then misleadingly logs that the plugin was skipped. The assessed vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) confirms this is a local, supply-chain-style prerequisite: an attacker must first get a third-party or compromised package installed and registered, and Docling must then be started by a user, so there is no remote network exploitation path. No public exploit code or active exploitation is known at time of analysis (EPSS 0.11%, percentile 1%; CISA SSVC exploitation: none), and the vendor has shipped a fix in 2.131.0.
Docling 2.94.0 through 2.131.x allows an attacker-supplied LaTeX/TikZ document to read files accessible to the converter process and create or overwrite writable files when the caller has explicitly opted into Tectonic rendering via LatexBackendOptions(tikz_engine="tectonic"); enabling the additional tikz_engine_allow_shell_escape option escalates this to shell command execution through TeX. The default Docling configuration does not enable Tectonic rendering and is not affected, and exploitation further requires a victim or operator to feed the crafted document into the pipeline (UI:R), which is why the practical risk is conditional despite the high CVSS base score. Both docling and docling-slim are affected; the flaw is fully fixed in 2.132.0, EPSS is a low 0.30% (21st percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis.
Local file disclosure in Docling's OpenDocument backend (versions 2.107.0 through 2.120.3) allows an attacker-supplied ODF file to force the parser to read arbitrary filesystem paths. When a draw:image element's xlink:href references a part missing from the document archive, the vulnerable backend treats the href as a local filesystem path without a scheme check or extraction-directory confinement, then embeds Pillow-decodable files into the converted output; non-image paths still leak existence information through read success or failure. Exploitation requires a victim or automated pipeline to convert a malicious ODF document (UI:A) in an unauthenticated network-reachable context (PR:N), and no public exploit code or CISA KEV active-exploitation entry has been identified at time of analysis. Note that on affected versions this code path bypassed the enable_local_fetch setting that other Docling backends honor, so the read occurred regardless of that configuration. The vulnerability is fixed in 2.120.3.
Unbounded rowspan/colspan attribute handling in Docling 2.0.0 through 2.130.x lets a deliberately crafted document force sustained CPU consumption or multi-gigabyte memory allocation during table parsing, denying service to the process doing the conversion. Four document backends are affected - HTML, JATS, OpenDocument spreadsheet, and BoxNote - and the built-in document_timeout setting does not interrupt the single backend conversion call, so the usual safeguard against runaway parses is ineffective. The flaw is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H): unauthenticated from the network but requiring the target to ingest the malicious file, with availability as the sole impact. No public exploit code identified at time of analysis, and the vulnerability is fixed in 2.131.0.
Information disclosure in Docling (and the docling-slim distribution) versions 2.16.0 through 2.130.x lets an attacker embed local file paths or file: URIs inside a crafted DoclingDocument JSON that, when re-converted and enriched or exported with ImageRefMode.EMBEDDED, causes Docling to open and embed the referenced file's bytes into Markdown or HTML output. Per the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, score 4.3), no privileges are needed but the victim must actively load the malicious JSON, and exposure is constrained to files Pillow can decode as images, with differing decode behavior potentially revealing whether a path exists. There is no public exploit code identified at time of analysis and the issue is not listed in CISA KEV; the flaw is fixed in Docling 2.131.0.
Processing a crafted document with Docling (or the docling-slim distribution) versions 2.45.0 through 2.130.x can exhaust process memory: a small gzip-compressed tar archive that declares a very large number of empty members causes the full archive member list to be materialised before the configured max_member_count limit can stop processing. The flaw sits in METS-GBS format detection (docling/datamodel/document.py) and the METS-GBS backend (docling/backend/mets_gbs_backend.py), and because detection runs before the allowed_formats restriction is applied, an attacker does not need METS-GBS to be an enabled format - remote, unauthenticated delivery is possible per the CVSS vector (AV:N/PR:N), though a user or automated pipeline must actually submit the file (UI:R), and the resulting impact is limited to availability (A:L, CVSS 4.3) with no code execution or data disclosure. No public exploit code was identified at time of analysis and the issue is not recorded as actively exploited; a vendor fix is available in 2.131.0.
Docling 2.83.0 through 2.130.x ignores the enable_remote_services=False policy when OCR is configured with KserveV2OcrOptions, so page-image crops are still transmitted to the caller-configured KServe v2/Triton inference endpoint during PDF processing. The defect is a security-control bypass rather than attacker-driven exfiltration: the remote destination is chosen by the operator, the vulnerable code path is inert unless a second, non-default remote OCR engine is explicitly configured, and satisfying the assessed vector (AV:L/AC:H/PR:H) requires local access with high privileges. The assessed impact is confined to low-severity confidentiality exposure of processed page images, with no integrity, availability, or code-execution effect; no public exploit code and no CISA KEV entry were identified at time of analysis, and the flaw is fixed in 2.131.0.
Server-side request forgery in Docling 2.91.0 through 2.131.x lets an attacker-supplied document reach internal services whenever remote document fetching is explicitly enabled, because validate_url_safety in docling/backend/utils/image_resource_loader.py performs only a single IPv4 lookup before the HTTP client re-resolves and parses the original URL. The same trust gap applies to HTMLBackendOptions(render_page=True), which issues HTTP and HTTPS browser requests without validating their resolved destination, so exploitation also covers DNS rebinding, mixed public/internal address records, and backslash-authority parser disagreement. Exploitation is gated by non-default configuration (fetch_images=True with enable_remote_fetch=True, --html-image-fetch remote, or render_page=True), requires the attacker to supply a processed document and win a rebinding timing race, and exposure is limited to responses successfully decoded as images or passively captured in a page screenshot; CVSS 3.1 is 4.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N), no public exploit identified at time of analysis, and the issue is fixed in 2.132.0.
Docling's HTML backend forwards operator-configured HTTP headers - bearer tokens, API keys, cookies set via HTMLBackendOptions.headers - to every remote image URL named by an untrusted HTML document, including after a cross-origin redirect, leaking the caller's credentials to whoever authored the document. The flaw lives in docling/backend/utils/image_resource_loader.py in versions 2.95.0 through 2.131.x and is only reachable in a deliberately non-default configuration where both enable_remote_fetch and fetch_images are enabled and sensitive headers have been configured; the default configuration carries no exposure. Upstream scored it CVSS 3.7, while independent assessment rates the confidentiality impact as High given that live credentials are disclosed; no public exploit code has been identified at time of analysis, and the issue is fixed in 2.132.0.