- Docling versions 2.27.0 up to 2.131.0 imported every registered plugin module before checking the setting meant to block external plugins, according to NIST's NVD record for CVE-2026-105745.
- The record says a later filter wrongly reported that the plugin was not loaded, so its report could mislead teams relying on that setting.
- Upgrade to 2.131.0 or later and review which installed packages register with Docling.
A safety switch that checks too late
A security setting is a promise. It tells your team that something will not happen. CVE-2026-105745 describes a promise that was made in the settings and broken in the order of operations.
The NIST National Vulnerability Database (NVD) published the record on October 5, 2026. It covers Docling, a tool that parses many document formats and connects to the generative AI ecosystem. Docling has a setting called allow_external_plugins, meant to stop outside add-ons from loading. In versions 2.27.0 up to 2.131.0, that setting did not stop them.
How the flaw works
Python programs can let add-on packages announce themselves through a registry called entry points. Docling keeps its own group in that registry. When Docling starts, its plugin factories look up the add-ons listed there.
The NVD record places the problem in the file docling/models/factories/base_factory.py. There, the factories call a loader function, load_setuptools_entrypoints(), before they apply the allow_external_plugins setting. By the time the setting is consulted, every add-on registered in the Docling group has already been imported.
Importing a Python module runs its top-level code. So any installed package that registers itself can run code the moment Docling starts. The record calls this import-time code.
The record adds a second problem. A namespace filter runs after the import and "misleadingly" reports that the plugin was not loaded. Think of a club that checks the guest list after the guest has walked in, then stamps "not admitted" on the sheet.
Who carries the risk
The attacker in this record needs a foothold. The NVD describes an installed third-party or compromised package. That points to the dependency tree, not to a stranger on the internet.
The scoring reflects that. The CVSS 3.1 base score is 6.7, rated medium. The vector marks the attack as local, with high complexity, low privileges and user interaction required. It rates the impact on confidentiality, integrity and availability as high. GitHub's security advisories team assigned the score.
The record does not report any attack in the wild. It does not name a malicious package either. Treat this as a defect that has been found and fixed, not as a known incident.
The lesson: the control and the evidence both failed
The usual lesson is to patch. The sharper one is about trust. A team that turned off external plugins, then saw a report that the plugin was not loaded, had every reason to believe the control worked. In the affected versions, the setting did not stop the import and the report was misleading.
This shows why a setting is not a control until someone has tested it. Tools that read documents and feed AI pipelines are often wired into many other packages. Each package that can register itself is a place where trust can slip. That is an inference from how plugins work, not a finding of the record.
What to ask your team
First, ask where Docling runs and which version each place uses. Anything from 2.27.0 up to, but not including, 2.131.0 is in the affected range. The fix is in 2.131.0, and the project's release notes and advisory GHSA-9jxx-vjrv-h2rq are listed in the NVD references.
Second, ask which installed packages register in the Docling entry-point group. If the answer is nobody knows, that is the finding.
Third, ask whether anyone relied on allow_external_plugins as a safeguard. If so, the filter's result saying the plugin was not loaded cannot serve as evidence for the affected versions.
Fourth, ask how packages reach those environments. A control that stops outside code from running matters less if anyone can install the package first.
A switch that cannot be trusted to say what it did is a switch worth testing before you rely on it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
