CVE-2026-105749: Unbounded Table Attributes in Docling Backends Leads to Resource Exhaustion

Docling is an enterprise-oriented, open-source Python library used to parse, segment, and convert complex document formats into structured, machine-readable formats. It serves as a critical component in automated ingestion pipelines, Retrieval-Augmented Generation (RAG) frameworks, and Large Language Model (LLM) workflows.

The library supports various data backends, adapting its conversion mechanisms for different input file types. These backends parse structured tables (such as HTML, JATS XML, OpenDocument Spreadsheet, and BoxNote JSON documents) to build structured layout matrices. To properly model these tables, the parsers reconstruct the physical arrangement of overlapping grid structures.

In vulnerable versions (prior to 2.131.0), the parsing adapters accepted row and column span attributes without verifying their scale against reasonable upper bounds. This missing validation exposes applications using Docling to uncontrolled resource exhaustion attacks. When processing a crafted file with highly inflated span coordinates, the target system encounters complete resource starvation.

The vulnerability stems from the combined effects of Uncontrolled Resource Consumption (CWE-400) and Memory Allocation with an Excessive Size Value (CWE-789). When Docling ingests tables, the underlying backend adapter instantiates a two-dimensional grid array to map spans and calculate intersecting coordinates. This mapping ensures subsequent processing steps maintain precise cell layout tracking.

Prior to the patch, when the parser processed attributes such as 'rowspan' or 'colspan', it converted the raw metadata strings directly into integers. The parser utilized these values to drive nested execution loops that initialized virtual table cells and populated spatial coordinate sets. An attacker can set these integers to extreme values, forcing the execution of intensive loops that map millions of coordinate intersections.

Because Python objects carry measurable heap memory overhead, allocating large tables or tracking their indexes in coordinate loops leads to quick memory exhaustion. The execution time and memory footprint scale exponentially relative to the magnitude of the supplied span attributes.

Furthermore, Docling provides a 'document_timeout' feature to limit execution runs, but this mechanism is only evaluated between pipeline phases. Because the synchronous table-parsing logic executes inside a single continuous phase, the parser cannot yield control to the scheduler. The timeout check is bypassed entirely, leaving the system to run until it is terminated by an out-of-memory handler or host system starvation.

The remediation implemented in commit c5b4429cc6500a344c13edeb22e67610c2159b09 addresses the root cause of the resource exhaustion by introducing a static-limit check and context-aware dynamic clamping.

The developers created docling/backend/utils/table_spans.py to define static limits for table attributes:

# Standard limits introduced to prevent algorithmic complexity attacks
MAX_COLSPAN = 1000
MAX_ROWSPAN = 65534
 
def clamp_span(span: int, limit: int) -> int:
    """Clamp a declared span to the safe range [1, limit]."""
    return max(1, min(span, limit))

To prevent a secondary CPU consumption vector—where an exceptionally long digit string causes resource exhaustion during string-to-integer conversion—the code restricts the length of processed numeric substrings before conversion. This logic is implemented in the _extract_num method in html_backend.py:

# Pre-validation check of string lengths to prevent parsing exhaustion
digits = match.group().lstrip('0')
if len(digits) > len(str(MAX_ROWSPAN)):
    return MAX_ROWSPAN
return max(int(digits or '0'), 1)

In addition to static limits, the backends apply dynamic clamping based on the table's physically detected layout. This context-aware bounding is implemented across the distinct parser adapters as shown below:

# Dynamic layout clamping inside boxnote_backend.py
row_span = min(
    _declared_span(cell, 'rowspan', MAX_ROWSPAN),
    len(rows) - row_idx,
)
col_span = min(
    _declared_span(cell, 'colspan', MAX_COLSPAN),
    max(width - col_idx, 1),
)

By ensuring that cells are constrained to both safe static boundaries and the physical boundaries of the table region, the processing complexity remains directly proportional to the actual structural properties of the document.

An attack targeting this vulnerability requires zero authentication and minimal operational overhead. The vulnerability can be triggered remotely by supplying a crafted document file to any application utilizing the Docling library for document parsing or automated content ingestion.

A malicious actor can construct a small HTML document containing highly disproportionate table properties to target the underlying HTMLDocumentBackend:

<table>
  <tr>
    <td rowspan='999999999'>Payload Column A</td>
    <td colspan='999999999'>Payload Column B</td>
  </tr>
  <tr>
    <td>Additional Row</td>
  </tr>
</table>

When Docling ingests this file, the conversion process attempts to initialize and iterate over a matrix of size 999999999 x 999999999. This operation triggers immediate heap-allocation calls and locks the active thread in a continuous execution loop.

The exploitation characteristics are highly asymmetric. The malicious payload requires less than a kilobyte of network bandwidth to transmit, yet it causes gigabytes of memory allocation on the server side within milliseconds, leading to a denial of service.

The successful exploitation of CVE-2026-105749 results in a complete denial of service for the host processing system. Because the vulnerability targets fundamental document parsers, its downstream impact is amplified in automated production environments.

In Retrieval-Augmented Generation (RAG) environments, document parsing pipelines often ingest and chunk large volumes of user-supplied business files. A single malicious upload can crash the parsing service, disabling the ingestion pipeline for all legitimate users. This risk is especially critical in multitenant applications where document ingestion shares physical host resources with core application components.

Because the host process memory limit is quickly exceeded, the operating system's Out-of-Memory (OOM) killer will typically terminate the parent process. In microservice architectures, such as Kubernetes clusters, continuous container crashes can trigger CrashLoopBackOff states. This destabilizes the local service cluster, resulting in broader infrastructure degradation.

This vulnerability has been assigned a CVSS score of 6.5 (Medium), reflecting high availability impact but low confidentiality or integrity exposure. Because exploiting the flaw requires zero authentication or specific privileges, it is highly attractive to adversaries seeking to execute low-cost denial of service attacks.

Remediation requires upgrading the docling package to version 2.131.0 or higher, which imports docling-core version 2.98.0 or higher. Organizations should verify their current python environment version using pip dependency tools:

pip list | grep docling

If upgrading cannot be implemented immediately, systems can deploy input validation filters to analyze incoming files before they are processed by Docling. Organizations should screen uploaded XML, HTML, and ODS content using regular expressions to detect anomalous span configurations:

(colspan|rowspan)\s*=\s*['"](9{4,}|\d{5,})['"]

Additionally, parsing operations should be isolated within containers with strict memory limits enforced by control groups (cgroups). This deployment pattern ensures that an Out-of-Memory event terminates only the worker container, protecting the parent system and neighboring processes from cascading failures.