CVE-2026-78163
Camel-Docling: Unvalidated message body input source enables server-side request forgery and local file disclosure in DoclingProducer
Description
DoclingProducer decided what a String message body meant by inspecting its prefix. A body starting with http:// or https:// was handed to Docling as a remote URL to fetch, a body starting with / or containing a backslash was read from the local filesystem, and anything else was written to a temporary file and converted as document content. The mode was chosen implicitly and no endpoint option allowed a route author to pin the component to a single interpretation, so a route that means "convert whatever text arrives in the body" silently became a fetcher of remote resources or a reader of local files whenever the text happened to begin with one of those prefixes. The only guard applied to the derived value was a size check, and that check was wrapped in an existence test, so a path that resolved to nothing, or to a pseudo-file reporting a size of zero, passed without being checked at all. Five call sites reached the two sinks: the CLI mode appended the value as the final positional argument of the docling subprocess, and the docling-serve mode passed it either to HttpSource for the backend to fetch or to Files.readAllBytes so that the content could be base64-encoded and uploaded. Because the exchange body is never filtered by a HeaderFilterStrategy, unlike the Camel header namespace, a sender able to place text in a message that a route forwards into a docling endpoint could reach both sinks without any opt-in from the deployment.
Mitigation
Credit
This issue was discovered by Li Zhiyao (BUPT)
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24422 refers to the commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25596 (commit 8b95ef19002a86ed530563a6df0772140ddb5cd0), and backported to camel-4.22.x in https://github.com/apache/camel/pull/25733 (commit 13909b1cb931cf0d38ee3170f5399510fe49d1eb) and to camel-4.18.x in https://github.com/apache/camel/pull/25744 (commit 5e6d0c94735102e5ea9bc249dd27042cd9157cb8).
A String message body is now treated as the document itself by default. The two location readings became opt-in through two new endpoint options, allowUrlSource and allowFilePathSource, both defaulting to false; a body that looks like a URL or a path is otherwise rejected with an IllegalArgumentException naming the option that would enable it. A further inputBaseDirectory option, unset by default, confines every local input path to a configured directory, normalizing lexically and comparing on path-segment boundaries so that a sibling directory sharing a name prefix with the base is not accepted. Only a bare String body is gated, because only it is ambiguous: the CamelDoclingInputFilePath header, File, byte[] and InputStream bodies, and the explicit path collections accepted by the batch operations all state their meaning already and continue to work without an opt-in, while remaining subject to inputBaseDirectory. The duplicated prefix tests at the five call sites were collapsed into a single helper so that new handling cannot be added to some of them and missed in others, and the size check was renamed to make its partial nature visible at every call site, with a new validation path that requires a local input path to exist and reports a missing one before Docling is invoked.
The local file disclosure has been present since camel-docling was introduced in 4.15.0. The remote URL sink was added later, in 4.16.0, when docling-serve support was introduced, so releases in the 4.15.x line are affected by the file disclosure only.
This advisory is distinct from CVE-2026-40047, which concerned insufficient validation of the CamelDoclingCustomArguments header in the same component and was fixed in 4.18.3 and 4.19.0. That fix was scoped to the custom-argument allowlist and did not touch the body-derived input path described here. Reaching this issue is also easier, because the Camel header namespace is filtered at consumer boundaries by the default HeaderFilterStrategy whereas the message body never is. It is classified as CWE-918 (Server-Side Request Forgery), CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).