CVE-2026-105747 in docling
Summary
by MITRE • 10/06/2026
Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.45.0 until 2.131.0, METS-GBS format detection in docling/datamodel/document.py and the backend in docling/backend/mets_gbs_backend.py call tarfile.TarFile.getmembers() before enforcing the max_member_count limit, causing the full archive member list to be allocated before the limit can stop processing. A small gzip-compressed tar archive with a very large number of empty members can therefore consume memory proportional to the declared member count, including during format detection before the allowed_formats restriction is applied. This issue is a residual weakness in the member-count protection added for CVE-2026-44018. This issue is fixed in 2.131.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within Docling versions ranging from 2.45.0 to 2.131.0 represents a critical resource exhaustion flaw rooted in the improper handling of archive member counts during format detection and processing phases. Docling is designed as a document processing library that parses diverse file formats, including METS-GBS, which often utilizes tar archives for internal structure. The core technical failure lies in the sequence of operations performed by the backend module docling/backend/mets_gbs_backend.py and the data model layer docling/datamodel/document.py. Specifically, these components invoke the Python standard library function tarfile.TarFile.getmembers() to inspect archive contents before applying a configured limit on the maximum number of allowed members. This ordering error means that the entire list of archive members is loaded into memory simultaneously prior to any validation logic capable of rejecting excessively large archives. Consequently, an attacker can craft a malicious METS-GBS file containing a gzip-compressed tar archive with a deliberately inflated member count consisting largely of empty entries. Upon processing such a file, the application attempts to allocate memory proportional to the declared number of members rather than the actual size or content density, leading to rapid and uncontrolled memory consumption that can result in an out-of-memory condition or complete denial of service for the hosting system or service utilizing Docling.
This flaw is classified as a residual weakness resulting from incomplete remediation efforts associated with CVE-2026-44018, which previously addressed similar issues related to archive member limits but failed to account for all code paths where this validation must occur. From an industry standard perspective, this vulnerability aligns closely with CWE-770: Allocation of Resources Without Limits or Throttling and CWE-400: Uncontrolled Resource Consumption. The attack vector allows for remote exploitation if the application processes untrusted documents via a web interface or API, making it particularly dangerous in cloud-native environments where resource limits are critical for stability. In terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1496: Resource Hijacking, specifically under sub-techniques involving denial-of-service through resource exhaustion. The exploitation does not require code execution but rather focuses on destabilizing the target environment by forcing it to allocate excessive memory resources based on maliciously crafted metadata within a seemingly benign document format.
The operational impact of this vulnerability extends beyond simple application crashes. In production environments, particularly those running Docling as part of a larger generative AI pipeline or document ingestion service, such resource exhaustion can lead to cascading failures across dependent services. If the host system runs out of available memory, it may begin swapping to disk, causing severe performance degradation for all processes on that machine, or trigger automatic restarts by container orchestration platforms like Kubernetes, leading to intermittent availability issues. Furthermore, because this flaw occurs during format detection before stricter allow-list restrictions are applied, even files intended for other formats can potentially trigger the vulnerability if they contain embedded METS-GBS structures with malicious tar archives, broadening the attack surface beyond just explicitly targeted file types.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. The primary remediation is to upgrade Docling to version 2.131.0 or later, where this specific ordering issue has been resolved by ensuring that member count limits are enforced before the full list of members is retrieved from the archive stream. For organizations unable to immediately update their dependencies, implementing strict resource quotas at the container or process level can help contain the blast radius of such an attack. Additionally, integrating input validation layers that inspect file headers and sizes prior to handing them over to parsing libraries like Docling can provide a secondary defense mechanism. Developers should also review other areas in their codebase where archive processing occurs to ensure that similar patterns of loading full member lists before applying limits are not present elsewhere, thereby preventing the recurrence of this class of resource exhaustion vulnerabilities across the entire application stack.