GHSA-3cr3-8m4c-fpxw: Medium severity pip/docling-slim vulnerability
Summary
When docling detects the input format of a gzip-compressed tar archive (METS-GBS), and later when the METS-GBS backend opens it, it calls tarfile.TarFile.getmembers(). That builds the full member list in memory before the maxmembercount limit is checked. A small archive with a very large number of empty members therefore makes docling allocate memory in proportion to the member count, and the limit has no effect.
Details
docling/datamodel/document.py (format detection) and docling/backend/metsgbsbackend.py both iterate tar.getmembers() and count members inside the loop. getmembers() reads every header up front.
Measured on Python 3.12: an archive of 1,000,000 empty members compresses to about 6.2 MB and makes getmembers() hold about 408 MB (about 66 times the input size). Format detection runs for any application/gzip input before allowedformats is applied, so the allocation happens even when METS-GBS is not an allowed format.
This check was introduced by the fix for CVE-2026-44018 (GHSA-r3xg-rg9j-67fv) in 2.91.0. The eager enumeration it relies on has been there since METS-GBS detection was added in 2.45.0.
Impact
Memory exhaustion of the converting process, proportional to the size of the input archive. Confidentiality and integrity are not affected.
Patches
Fixed in docling 2.131.0 by #4412. Format detection and the METS-GBS backend now read archive members one at a time and stop as soon as maxmembercount is exceeded, including when looking up page files.
Workarounds
Upgrade to 2.131.0. For older versions:
Reject gzip or tar inputs before they reach docling when METS-GBS support is not needed, and run conversions of untrusted input with memory limits.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/docling-slimto a version that resolves this vulnerability.Fixed in 2.131.0 - Upgrade
Upgrade
pip/doclingto a version that resolves this vulnerability.Fixed in 2.131.0 - Upgrade
Upgrade
doclingto a version that resolves this vulnerability.Fixed in 2.131.0 - Compensating control
Reject gzip or tar inputs before they reach docling when METS-GBS support is not needed.
- Compensating control
Run conversions of untrusted input with memory limits.
Event History
Frequently Asked Questions
Are deployments that do not allow METS-GBS input still exposed?
Yes. Format detection runs for any application/gzip input before allowed_formats is applied. A gzip-compressed tar archive can therefore trigger the allocation even when METS-GBS is not an allowed format.
What must an attacker provide to cause the memory allocation?
The attacker needs to cause docling to process a crafted gzip-compressed tar archive containing a very large number of empty members. A roughly 6.2 MB archive with 1,000,000 members was measured to cause getmembers() to retain about 408 MB of memory.
Does max_member_count prevent this condition?
No. tarfile.TarFile.getmembers() constructs the complete member list before docling counts members and checks max_member_count, so memory is allocated before the limit can take effect.
How can I determine whether my code path is affected?
Review whether the deployed docling version performs METS-GBS format detection or backend processing using tar.getmembers(). The eager enumeration has existed since METS-GBS detection was added in version 2.45.0; the max_member_count check described here was introduced in 2.91.0.