CVE-2026-108749 in docling-serve
Summary
by MITRE • 10/11/2026
docling-serve 1.14.0 through 1.36.0 contains a missing authentication vulnerability that allows unauthenticated attackers to access /v1/memory/stats and /v1/memory/counts because they omit the require_auth dependency. Attackers can bypass the configured DOCLING_SERVE_API_KEY to read process and cgroup memory telemetry, object type histograms, and force repeated gc.collect() heap enumeration.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in docling-serve versions 1.14.0 through 1.36.0 represents a critical authentication bypass resulting from improper implementation of access control mechanisms within the application's routing layer. Specifically, two endpoints designed to expose system telemetry data, namely /v1/memory/stats and /v1/memory/counts, were configured without enforcing the require_auth dependency that is applied to other sensitive routes in the service architecture. This architectural inconsistency allows unauthenticated actors to interact with these endpoints directly via standard HTTP requests, effectively circumventing the API key authentication mechanism defined by the DOCLING_SERVE_API_KEY environment variable. The root cause lies in a configuration oversight where specific route definitions failed to inherit or explicitly apply the global authentication middleware, creating an unintended open door for external access.
From a technical perspective, this flaw enables attackers to extract detailed internal system metrics that are typically reserved for authorized administrators or monitoring tools. By accessing /v1/memory/stats and /v1/memory/counts, adversaries can retrieve process-level memory usage data, cgroup telemetry which provides insights into resource allocation limits and actual consumption at the container level, object type histograms detailing the distribution of Python objects in memory, and heap enumeration results triggered by forced garbage collection cycles. This information is highly sensitive as it reveals the internal state of the application server, including potential memory leaks, load patterns, and the specific types of data structures currently active within the process space. Such granular visibility into runtime behavior can serve as a reconnaissance step for more sophisticated attacks, allowing attackers to map out the system's resource constraints and operational characteristics without triggering security alerts associated with authentication failures.
The operational impact of this vulnerability extends beyond simple information disclosure. The ability to force repeated calls to gc.collect() through these endpoints introduces a potential vector for denial-of-service conditions. Since garbage collection is a computationally expensive operation that pauses application execution, an attacker could craft high-frequency requests to /v1/memory/stats or /v1/memory/counts to induce excessive CPU usage and latency spikes, thereby degrading service availability for legitimate users. Furthermore, the exposure of object type histograms and memory statistics can aid in crafting targeted exploitation attempts against other components within the same environment by revealing details about loaded libraries, installed packages, or specific framework versions running on the server. This level of insight reduces the effort required for subsequent attack phases such as privilege escalation or remote code execution if combined with other vulnerabilities present in the stack.
In alignment with industry standards, this vulnerability is classified under CWE-287, which denotes Improper Authentication, specifically highlighting the failure to verify identity before granting access to protected resources. It also aligns with CWE-200, Information Exposure, as it allows unauthorized parties to gain insight into system internals that should remain confidential. From a threat modeling perspective using the MITRE ATT&CK framework, this behavior corresponds to T1592.004, Gather Victim Host Information via Local Network Access, and potentially T1496, Resource Hijacking if exploited for denial-of-service purposes through resource exhaustion techniques like forced garbage collection cycles. The lack of authentication on these specific endpoints violates the principle of least privilege by exposing diagnostic data that is not required for normal application functionality to unauthenticated users.
To mitigate this vulnerability, immediate remediation involves updating docling-serve to a version later than 1.36.0 where the routing configuration has been corrected to enforce authentication across all telemetry and monitoring endpoints. If an update is not immediately feasible, administrators should implement network-level controls such as firewall rules or reverse proxy configurations that restrict access to these specific URL paths based on IP allow-listing for trusted internal networks only. Additionally, deploying a Web Application Firewall with rule sets capable of detecting abnormal request frequencies can help mitigate the denial-of-service risk associated with forced garbage collection calls. It is also recommended to audit all other endpoints in the application to ensure consistent application of authentication middleware and to verify that no other routes have been inadvertently left unprotected due to similar configuration oversights during development or deployment processes.