Summary
Docling Core versions 1.5.0 through 2.74.0 insufficiently restrict remote request destinations and resolve server-provided Content-Disposition headers to local file paths in an unsafe way.
In applications that pass untrusted URLs into Docling Core, this behavior can enable server-side request forgery against local resources and access to files outside the intended cache directory.
Docling Core versions 1.5.0 through 2.74.0 insufficiently restrict remote request destinations and resolve server-provided Content-Disposition headers to local file paths in an unsafe way.
In applications that pass untrusted URLs into Docling Core, this behavior can enable server-side request forgery against local resources and access to files outside the intended cache directory.
Affected context
This vulnerability arises when applications integrate Docling Core (versions 1.5.0 to 2.74.0) and allow users or external systems to supply arbitrary URLs for document processing.
Docling Core may follow these URLs and honor Content-Disposition headers from the remote server, resolving them into local file paths without enforcing strict destination and path constraints.
The risk is greatest in deployments where the processing service has network access to internal resources or sensitive local files and where the cache directory is expected to be the only write target.
This vulnerability arises when applications integrate Docling Core (versions 1.5.0 to 2.74.0) and allow users or external systems to supply arbitrary URLs for document processing.
Docling Core may follow these URLs and honor Content-Disposition headers from the remote server, resolving them into local file paths without enforcing strict destination and path constraints.
The risk is greatest in deployments where the processing service has network access to internal resources or sensitive local files and where the cache directory is expected to be the only write target.
Exploit preconditions
- Attack surface: HTTP(S) endpoints or APIs that forward untrusted URLs into Docling Core for fetching or processing.
- Required access: Ability to submit or influence the URLs that Docling Core retrieves (e.g., through web forms, APIs, workflow configurations, or upstream services).
- Trigger point: Docling Core performs a remote request and processes the server response, including Content-Disposition, to determine where to store the resulting file.
- Why exploitation is possible: Network destinations are not sufficiently restricted (allowing access to internal or loopback addresses), and the resolved file path derived from Content-Disposition is not robustly constrained to the user-defined cache directory, enabling writes outside the intended location.
- Attack surface: HTTP(S) endpoints or APIs that forward untrusted URLs into Docling Core for fetching or processing.
- Required access: Ability to submit or influence the URLs that Docling Core retrieves (e.g., through web forms, APIs, workflow configurations, or upstream services).
- Trigger point: Docling Core performs a remote request and processes the server response, including Content-Disposition, to determine where to store the resulting file.
- Why exploitation is possible: Network destinations are not sufficiently restricted (allowing access to internal or loopback addresses), and the resolved file path derived from Content-Disposition is not robustly constrained to the user-defined cache directory, enabling writes outside the intended location.
Why this happens
The core issue combines insufficient control over outbound requests with unsafe handling of server-controlled metadata.
Docling Core trusts server-provided Content-Disposition values to derive local file paths without fully normalizing and constraining them to a designated cache directory, reflecting CWE-22: Path Traversal.
At the same time, the component allows requests to arbitrary destinations, including potentially internal or local services, aligning with CWE-918: Server-Side Request Forgery.
The underlying pattern is a lack of strict allow-listing for network targets and inadequate enforcement of filesystem boundaries when mapping remote responses to local storage.
The core issue combines insufficient control over outbound requests with unsafe handling of server-controlled metadata.
Docling Core trusts server-provided Content-Disposition values to derive local file paths without fully normalizing and constraining them to a designated cache directory, reflecting CWE-22: Path Traversal.
At the same time, the component allows requests to arbitrary destinations, including potentially internal or local services, aligning with CWE-918: Server-Side Request Forgery.
The underlying pattern is a lack of strict allow-listing for network targets and inadequate enforcement of filesystem boundaries when mapping remote responses to local storage.
Potential impact
- SSRF attempts targeting internal HTTP services, metadata endpoints, or other non-public infrastructure the server can reach
- Reading or influencing local files that reside outside the intended cache directory, depending on how the application later uses stored files
- Circumventing network segmentation assumptions by using the Docling Core host as a proxy to internal or loopback-only services
- Facilitating follow-on attacks if internal responses contain secrets, tokens, or configuration details
- Interference with application behavior by overwriting or planting files in unexpected locations (where permissions allow)
- SSRF attempts targeting internal HTTP services, metadata endpoints, or other non-public infrastructure the server can reach
- Reading or influencing local files that reside outside the intended cache directory, depending on how the application later uses stored files
- Circumventing network segmentation assumptions by using the Docling Core host as a proxy to internal or loopback-only services
- Facilitating follow-on attacks if internal responses contain secrets, tokens, or configuration details
- Interference with application behavior by overwriting or planting files in unexpected locations (where permissions allow)
General mitigation guidance
Mitigation generally focuses on tightening both network egress and filesystem write constraints around document fetching and storage.
Defensively, applications that integrate Docling Core can:
- Restrict the set of allowed URL schemes and remote hosts, ideally via an explicit allow-list aligned with business needs.
- Block or carefully scrutinize access to loopback, link-local, and internal address ranges from components handling untrusted URLs.
- Enforce strict normalization and validation of any paths derived from Content-Disposition or similar headers, ensuring that resolved paths cannot escape the designated cache or working directory.
- Run document-processing components with least-privilege filesystem permissions so that only expected directories are writable.
- Treat remote metadata (headers, filenames, redirects) as untrusted input to be sanitized and constrained prior to use.
Mitigation generally focuses on tightening both network egress and filesystem write constraints around document fetching and storage.
Defensively, applications that integrate Docling Core can:
- Restrict the set of allowed URL schemes and remote hosts, ideally via an explicit allow-list aligned with business needs.
- Block or carefully scrutinize access to loopback, link-local, and internal address ranges from components handling untrusted URLs.
- Enforce strict normalization and validation of any paths derived from Content-Disposition or similar headers, ensuring that resolved paths cannot escape the designated cache or working directory.
- Run document-processing components with least-privilege filesystem permissions so that only expected directories are writable.
- Treat remote metadata (headers, filenames, redirects) as untrusted input to be sanitized and constrained prior to use.
How teams detect issues like this
Detection can combine static analysis, configuration review, and runtime monitoring.
Potential approaches include:
- Static analysis or code review searches for logic that forwards unvalidated user-supplied URLs to Docling Core or similar document-fetching APIs.
- Policy checks in CI pipelines to ensure outbound HTTP clients enforce host allow-lists and reject private or loopback address ranges when handling untrusted input.
- Review of path construction code that joins Content-Disposition-derived filenames or headers with local directories, verifying proper normalization and directory containment checks.
- Runtime monitoring for unusual outbound connections from the document-processing service to internal endpoints or unexpected IP ranges.
- Use of automated security testing tools (e.g., DAST or SSRF-focused scanners) against endpoints that accept URLs for document ingestion.
Detection can combine static analysis, configuration review, and runtime monitoring.
Potential approaches include:
- Static analysis or code review searches for logic that forwards unvalidated user-supplied URLs to Docling Core or similar document-fetching APIs.
- Policy checks in CI pipelines to ensure outbound HTTP clients enforce host allow-lists and reject private or loopback address ranges when handling untrusted input.
- Review of path construction code that joins Content-Disposition-derived filenames or headers with local directories, verifying proper normalization and directory containment checks.
- Runtime monitoring for unusual outbound connections from the document-processing service to internal endpoints or unexpected IP ranges.
- Use of automated security testing tools (e.g., DAST or SSRF-focused scanners) against endpoints that accept URLs for document ingestion.
