CVE-2026-105742 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.95.0 until 2.132.0, the HTML image resource loader in docling/backend/utils/image_resource_loader.py forwards headers configured through the HTMLBackendOptions.headers setting to every remote image URL named by an untrusted document when enable_remote_fetch=True and fetch_images=True. The loader does not restrict those credentials to the source document's origin, allowing requests that carry custom headers such as API keys and cookies to follow cross-origin redirects and expose the caller's configured credentials to a document author. The default configuration is not affected because remote fetching and configured headers are required. This issue is fixed in 2.132.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Docling versions from 2.95.0 through 2.132.0 represents a significant security flaw within the document processing pipeline, specifically affecting the HTML image resource loader located in the backend utilities module. This component is responsible for fetching external resources referenced by parsed documents to ensure complete rendering and data extraction. The core technical deficiency lies in how HTTP headers configured via the HTMLBackendOptions.headers setting are propagated during these fetch operations. When a user configures custom headers, such as authentication tokens or API keys, and enables remote image fetching through specific boolean flags, the loader indiscriminately attaches these credentials to every outgoing request for an external image URL specified within the untrusted document content. This behavior persists regardless of whether the target domain matches the origin of the source document itself.
This lack of origin restriction creates a classic cross-origin credential leakage scenario. An attacker who controls or influences the content of a processed HTML document can embed references to maliciously crafted remote images hosted on an attacker-controlled server. When Docling processes such a document with remote fetching enabled, it initiates HTTP requests to these external URLs while automatically including sensitive headers configured by the application owner. These credentials are not only sent in the initial request but also follow cross-origin redirects. If the target URL responds with a redirect status code pointing to another domain, the browser-like behavior of the loader ensures that the custom headers continue to be transmitted to the final destination. This mechanism allows document authors or attackers to exfiltrate sensitive authentication data from the calling environment without any user interaction beyond the submission of the malicious file for processing.
The operational impact of this vulnerability is severe in environments where Docling is integrated into generative AI ecosystems or automated document analysis pipelines that handle untrusted input. The exposure of API keys, session cookies, or other proprietary credentials can lead to unauthorized access to backend services, data breaches, and potential compromise of the underlying infrastructure. Since the default configuration typically does not enable remote fetching by default, the immediate risk is mitigated for users who have not explicitly opted into this feature. However, in production environments where dynamic content processing requires external resource loading, the presence of configured headers combined with enabled remote fetch capabilities creates a high-severity attack vector. The vulnerability effectively turns the document parser into an unwitting proxy that leaks internal secrets to arbitrary third-party servers based solely on the content embedded within the processed file.
From a classification perspective, this issue aligns with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws where server-side code makes requests from untrusted input without validating whether the request should be allowed or what credentials are sent. It also relates to CWE-200, concerning Exposure of Sensitive Information to an Unauthorized Actor. In terms of offensive security frameworks, this behavior mirrors techniques found in MITRE ATT&CK under T1557, specifically Adversary-in-the-Middle scenarios where stolen credentials can be used for lateral movement or further exploitation. The vulnerability highlights the critical importance of implementing strict origin checks and ensuring that sensitive headers are stripped when making requests to domains outside a predefined trusted list.
To mitigate this risk, organizations must ensure they upgrade Docling to version 2.132.0 or later where the issue has been resolved by restricting header propagation to only those origins explicitly permitted by policy. For environments unable to immediately patch, administrators should disable remote image fetching entirely if it is not strictly required for their use case. If remote fetching must remain enabled, a robust allowlist of trusted domains should be configured so that requests are restricted exclusively to known and safe sources. Additionally, developers integrating Docling into larger applications should avoid passing sensitive authentication headers through the backend options unless absolutely necessary, opting instead for more secure methods of handling credentials such as environment variables or dedicated secret management systems that do not get serialized into request objects sent to arbitrary external endpoints.