CVE-2026-105745 in Docling
Summary
by MITRE • 10/05/2026
Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.27.0 until 2.131.0, Docling plugin factories in docling/models/factories/base_factory.py call load_setuptools_entrypoints() before applying the allow_external_plugins setting, so every module registered in the Docling entry-point group is imported even when external plugins are disabled. An installed third-party or compromised package can therefore execute import-time code when Docling starts, while the subsequent namespace filter misleadingly reports that the plugin was not loaded. This issue is fixed in 2.131.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within the Docling document processing library represents a critical failure in access control logic regarding third-party plugin integration. Specifically, this flaw exists between versions 2.27.0 and 2.131.0 of the software. The core issue resides in the initialization sequence defined in the base_factory.py module, where the system invokes load_setuptools_entrypoints() prior to evaluating the allow_external_plugins configuration setting. This ordering error creates a race condition-like scenario during application startup, wherein all modules registered under the Docling entry-point group are imported and their associated code is executed regardless of whether external plugins have been explicitly disabled by the administrator or user.
From a technical perspective, this behavior constitutes an improper restriction of functionality vulnerability. When Python imports a module, it executes any top-level code present in that file. Consequently, if a malicious third-party package or a compromised library is installed and registered as a Docling plugin, its import-time side effects will trigger automatically upon the launch of Docling. This execution occurs before the security filter can intervene to block the loading process. The situation is further exacerbated by misleading logging behavior; even though the code executes during this premature import phase, the subsequent namespace filtering logic incorrectly reports that the plugin was not loaded. This false sense of security prevents administrators from detecting unauthorized or malicious activity through standard monitoring tools.
The operational impact of this vulnerability is significant for any organization relying on Docling to process documents in untrusted environments. An attacker who can influence the installed packages within a Python environment could inject code into a seemingly benign plugin package. Upon execution, this injected code could perform arbitrary actions such as exfiltrating sensitive data from processed documents, establishing reverse shells, or modifying system configurations before any security controls are effectively applied. The lack of accurate logging means that incident response teams may remain unaware of the compromise until significant damage has occurred, complicating forensic analysis and remediation efforts.
This vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, as well as CWE-862, involving missing authorization checks in critical code paths. In terms of adversary tactics, this flaw facilitates initial access and persistence mechanisms described in the MITRE ATT&CK framework under techniques related to software deployment and component registration abuse. Attackers often leverage legitimate system features like plugin architectures to bypass security controls, a tactic known as living off the land or using trusted binaries for malicious purposes. The specific failure here is that the trust boundary was not enforced at the correct point in the initialization lifecycle.
To mitigate this risk, organizations must upgrade Docling to version 2.131.0 or later immediately. This release rectifies the ordering of operations by ensuring that security checks are performed before any external modules are imported. Until an upgrade is feasible, administrators should strictly audit all installed Python packages for those registered under the Docling entry-point group and remove any untrusted dependencies. Additionally, implementing strict dependency pinning policies in CI/CD pipelines can prevent accidental installation of vulnerable or malicious versions. Monitoring system logs for unexpected import activities during application startup may also provide early warning signs if an upgrade is delayed.