CVE-2026-40047
Camel-Docling: Insufficient validation of custom CLI arguments enables argument injection and path traversal in DoclingProducer
Description
The camel-docling component invokes the external `docling` command-line tool by assembling an argument list in DoclingProducer and executing it through java.lang.ProcessBuilder. Custom CLI arguments supplied through the `CamelDoclingCustomArguments` exchange header (a List<String>) were appended to that argument list with insufficient validation: the original implementation relied on a denylist of disallowed flags and only rejected path values that contained a literal `../` sequence. As a result, a Camel route that forwards externally-influenced data into the `CamelDoclingCustomArguments` header (or into the path-bearing headers used to build the invocation) could cause the producer to pass unrecognized or unintended `docling` CLI flags to the subprocess, and could supply path-like argument values that resolved outside the intended directory through traversal sequences not caught by the literal `../` check. Because Camel itself builds the `docling` invocation from these values, the component is responsible for constraining them, and the weak validation allowed CLI-argument injection and directory traversal in the arguments passed to the external tool. The invocation uses the list-based form of ProcessBuilder, so a shell does not interpret the argument values; OS command injection through shell metacharacters was not possible, and the metacharacter rejection added by the fix is defense-in-depth.
Mitigation
docling CLI flags (rejecting any unrecognized flag, and rejecting producer-managed flags such as the output-directory flags), defensively rejects shell metacharacters in argument values, and normalizes path-like values with Path.normalize() before validating them so that traversal sequences which bypass a literal ../ check are detected. As defence in depth, route authors should avoid mapping untrusted message content into the CamelDoclingCustomArguments header and the path-bearing headers, and should strip Camel-internal headers from messages that arrive from untrusted producers.Credit
This issue was discovered by Andrea Cosentino from Apache Software Foundation
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23212 refers to the commits that resolved the issue, and has more details.
The fix was merged on the main branch in https://github.com/apache/camel/pull/22082 (commit f86fda0442c65b9d13ce3aa8ac676233b64e3351) and is first available in the 4.19.0 release. The 4.18.x LTS backport is https://github.com/apache/camel/pull/22767 (commit 1fa56f45901f50aa79849ff2d2ca83dd57f6991c) and is included in the 4.18.3 release.