CVE-2026-105745: Arbitrary Code Execution via Malicious Entrypoint Discovery in Docling base_factory

Docling is an open-source document processing library widely used to parse and convert structured documents into machine-readable formats. To facilitate extensibility across various optical character recognition (OCR) systems and model pipelines, Docling implements a dynamic plugin discovery framework. This framework discovers and registers extension components configured as Python packaging entrypoints.

By design, Docling includes a configuration mechanism (allow_external_plugins=False) intended to restrict the loading of modules to officially supported namespaces starting with docling.. This flag is active by default in both CLI execution and programmatic API initializations to prevent unauthorized extensions from running.

However, a design flaw exists in how the discovery workflow is sequenced in the base factory engine. Under affected versions, Docling scans the execution environment and resolves all modules declared under the docling group identifier. Because the validation steps are deferred until after the entrypoints are processed, the system exposes an attack surface where installing any untrusted Python package locally leads to automatic execution of that package's import-time logic.

The underlying security flaw is classified under CWE-696 (Incorrect Behavior Order) and CWE-829 (Inclusion of Functionality from Untrusted Control Sphere). In the Python ecosystem, importing a module involves execution of all top-level statements, class definitions, and variable assignments within the target module scope. This behavior is standard and occurs prior to the module object being fully returned to the namespace.

Docling relied on the Pluggy library's PluginManager.load_setuptools_entrypoints() function to identify and register plugins. When Pluggy executes this command, it searches metadata for entrypoints registered under a specified group name. Once found, Pluggy automatically resolves and imports the backing modules so it can register the hook implementations defined within them.

The logic error in Docling's base factory occurs because load_setuptools_entrypoints() is called unconditionally at the beginning of the load_from_plugins function. This loading mechanism executes prior to checking the allow_external_plugins configuration parameter. While the code subsequently screens the module namespace and skips registering any unauthorized objects, the malicious side effects defined at the module's global level have already completed execution in the application's runtime.

To understand the implementation flow of the vulnerability, examine the deprecated code pattern in docling/models/factories/base_factory.py alongside the revised mitigation pattern.

Vulnerable Design

In the vulnerable implementation, all module discovery is executed via direct reliance on Pluggy's autoloader without verification of metadata string names first:

# File: docling/models/factories/base_factory.py (Vulnerable Implementation)
plugin_manager = PluginManager(plugin_name)
# Unconditionally imports all entrypoints declared under the specified plugin_name group
plugin_manager.load_setuptools_entrypoints(plugin_name)
 
for plugin_name, plugin_module in plugin_manager.list_name_plugin():
    plugin_module_name = str(plugin_module.__name__)
 
    # Validation check occurs AFTER import execution
    if not allow_external_plugins and not plugin_module_name.startswith("docling."):
        logger.warning(
            f"The plugin {plugin_name} will not be loaded because Docling is being executed with allow_external_plugins=false."
        )
        continue

Remediation Pattern

The patched implementation replaces bulk autoloading with standard library inspection via importlib.metadata.entry_points. This allows metadata parsing to filter by namespace string before importing the underlying module:

# File: docling/models/factories/base_factory.py (Patched in Commit 0f443b3786e98688a2da3b7c8f56fe5e46af876c)
from importlib.metadata import entry_points
 
plugin_manager = PluginManager(plugin_name)
 
# Query registered metadata structures instead of triggering imports
for entry_point in entry_points(group=plugin_name):
    if plugin_manager.get_plugin(entry_point.name) is not None:
        continue
 
    # Perform validation on the string metadata path before loading the module
    if not allow_external_plugins and not entry_point.module.startswith(
        "docling."
    ):
        logger.warning(
            f"The plugin {entry_point.name} will not be loaded because Docling is being executed with allow_external_plugins=false."
        )
        continue
 
    # Safe registration only after metadata validation passes
    plugin_manager.register(entry_point.load(), name=entry_point.name)

Technical Execution Flow

Exploitation of CVE-2026-105745 requires an attacker to place a package with a malformed or malicious entrypoint registration into the local Python package registry (sys.path). While this limitation makes exploitation complex, standard target vectors exist in supply chain spaces such as typosquatting on PyPI, dependency confusion within private registries, or exploiting pre-existing write access to local site-packages.

To construct a proof-of-concept, an attacker defines a dependency package configuration specifying an entrypoint within the target namespace group:

# File: pyproject.toml of malicious dependency
[project.entry-points."docling"]
malicious_payload = "untrusted_package.malicious_plugin"

The target file untrusted_package/malicious_plugin.py contains direct system execution logic inside the global/module execution context:

# File: untrusted_package/malicious_plugin.py
import os
import sys
 
# Code runs instantly upon being searched by pluggy
os.system("id > /tmp/compromised")

When Docling is executed on a document by a victim user within an environment where the payload package has been deployed, Docling's entrypoint resolution will automatically look for and load untrusted_package.malicious_plugin. This initiates execution of the target payload sequence, writing user shell privileges to /tmp/compromised before any evaluation checks block the plugin registration.

The impact of this vulnerability is local code execution with the same permissions as the execution context of the Docling tool. Because docling is frequently used in cloud-based parsing services, batch ingestion jobs, or large language model (LLM) data pipeline servers, this context often has elevated capabilities including read access to internal databases, cloud provider instance metadata services, and system environment credentials.

The CVSS v3.1 vector is rated as CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. The Attack Complexity is classified as High because it relies on placing malicious packages in the local environment, and User Interaction is Required since a user or system process must actively invoke Docling processes.

This behavior is highly impactful in automation settings where data workers run external open-source code inside multi-user shared execution nodes. The lack of proper isolation prior to dynamic imports allows an underprivileged tenant to compromise the active application server simply by installing a local package that register entrypoints under the standard group designations.

The primary resolution path for CVE-2026-105745 is upgrading to version 2.131.0 or newer. If utilizing the core sub-libraries directly, you should verify that docling-core has been upgraded to a version matching or exceeding 2.98.0.

In environments where upgrading dependencies immediately is unfeasible, several defense-in-depth measures should be taken:

1. Enforce strict python environment isolation by deploying applications within dedicated virtual environments or container constraints.
2. Configure file permission boundaries on site-packages folders to prevent write capabilities by non-administrator users, blocking arbitrary package installations.
3. Utilize standard package locking configurations (e.g., poetry.lock, requirements.txt with hashes) to enforce integrity validation on all dependencies to prevent dependency hijacking vectors.

Security administrators can inspect Python environments for rogue entrypoints under the docling group by running the following audit script:

import importlib.metadata
 
for ep in importlib.metadata.entry_points(group="docling"):
    is_valid = ep.module.startswith("docling.")
    status = "APPROVED" if is_valid else "WARNING: UNAUTHORIZED EXTERNAL MODULE"
    print(f"Entrypoint Name: {ep.name:25} | Module: {ep.module:40} | Status: {status}")