CVE-2026-40047: Apache Camel camel-docling improperly validates custom CLI arguments, enabling argument injection and path traversal when untrusted data is mapped into docling invocation headers.

• Affected versions: The ticket identifies Apache Camel 4.15.0 through 4.18.2. The reproduction exercises 4.16.0 and 4.18.2 as affected controls and 4.18.3 as the fixed control.
• Risk level and consequences: The ticket marks the issue critical. Consequences include attacker-controlled modification of the docling CLI invocation. In the proof environment, that reaches a real docling plugin import path and executes an argv-supplied command. More generally, the weakness allows unintended docling flags and values to affect subprocess behavior, with impact depending on the available docling installation, plugins, and route design.

Impact Parity

• Disclosed/claimed maximum impact: code_execution.
• Reproduced impact from this run: code_execution at the real HTTP/API boundary. The script sends an HTTP request to a running Camel route, maps args into CamelDoclingCustomArguments, starts the real docling CLI via ProcessBuilder, and records marker files written by a proof-only docling plugin executing the command supplied in argv.
• Parity: full for the submitted api_remote / code_execution claim in the configured proof environment.
• Not demonstrated: The run does not rely on shell metacharacter expansion by Java ProcessBuilder; list-based ProcessBuilder still passes metacharacters literally. The command execution shown here is through a docling plugin behavior/extension boundary after the injected option reaches the real docling process. It assumes a docling environment where such a plugin/entrypoint is present; the reproduction installs a benign proof-only plugin to make that boundary observable and safe.

Root Cause

Affected camel-docling versions appended the CamelDoclingCustomArguments header directly into the command list passed to java.lang.ProcessBuilder. The vulnerable flow is:

1. A Camel route receives remote HTTP input, for example GET /convert?args=....
2. Route code maps that string into CamelDoclingCustomArguments as a List<String>.
3. DoclingProducer.addCustomArguments() appends the list into the docling command.
4. DoclingProducer.executeDoclingCommand() starts new ProcessBuilder(command).start().
5. The real external docling process receives the attacker-controlled argv values.

In 4.16.0 there is no effective validation of custom arguments. In 4.18.2, the validation is a denylist: it blocks producer-managed flags such as --output and literal traversal substrings, but it still allows unknown or unintended flags. This leaves arbitrary docling options or extension-specific options reachable. In 4.18.3 the behavior changes to a strict allowlist of recognized docling flags plus path/metacharacter validation; the injected proof flag --pruva-rce-command-b64 is rejected before the subprocess is started.

The exact fixed commit hash was not provided in the ticket. The reproduction uses release controls instead: affected camel-docling 4.16.0 and 4.18.2, and fixed camel-docling 4.18.3.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh from any directory. It is self-contained and uses PRUVA_ROOT/relative bundle paths.
2. The script:
   • Reuses the prepared project cache at <project_cache_dir>/repo when available.
   • Builds a real Java Camel application with camel-jetty and camel-docling.
   • Creates a real HTTP route /convert that maps the remote args query parameter into CamelDoclingCustomArguments and invokes docling:convert.
   • Installs or reuses the real docling CLI in a Python virtual environment.
   • Installs a benign proof-only docling plugin. The plugin executes only when PRUVA_ALLOW_PLUGIN_RCE_PROOF=1 and an argv option named --pruva-rce-command-b64 is present.
   • Runs two affected attempts on Camel 4.16.0, two affected attempts on Camel 4.18.2, and two fixed negative-control attempts on Camel 4.18.3.
3. Expected evidence:
   • 4.16.0 and 4.18.2: the real docling wrapper logs ARGV: [0]=--pruva-rce-command-b64 ..., and marker files contain PRUVA_RCE_CONFIRMED version=<version> attempt=<n> uid=<uid>.
   • 4.18.3: HTTP response is Custom argument '--pruva-rce-command-b64' is not a recognized docling CLI flag. Only known docling flags are permitted as custom arguments., no docling invocation log is produced for the injected flag, and no marker file is written.

Evidence

Key evidence from the successful consecutive runtime runs is under bundle/logs/ and summarized in bundle/repro/runtime_manifest.json.

Important artifacts include:

• bundle/logs/reproduction_steps.log — full run summary.
• bundle/logs/http_transcript.log — HTTP requests and response previews for /convert?args=....
• bundle/logs/vulnerable_4.16.0_attempt1_docling_invocations.log and bundle/logs/vulnerable_4.16.0_attempt2_docling_invocations.log — real docling argv logs for 4.16.0.
• bundle/logs/vulnerable_4.16.0_attempt1_rce_marker.txt and bundle/logs/vulnerable_4.16.0_attempt2_rce_marker.txt — command-execution markers for 4.16.0.
• bundle/logs/vulnerable_4.18.2_attempt1_docling_invocations.log and bundle/logs/vulnerable_4.18.2_attempt2_docling_invocations.log — real docling argv logs for 4.18.2.
• bundle/logs/vulnerable_4.18.2_attempt1_rce_marker.txt and bundle/logs/vulnerable_4.18.2_attempt2_rce_marker.txt — command-execution markers for 4.18.2.
• bundle/logs/fixed_4.18.3_attempt1_response.txt and bundle/logs/fixed_4.18.3_attempt2_response.txt — fixed-version rejection evidence.
• bundle/repro/runtime_manifest.json — structured runtime evidence manifest.
• bundle/repro/validation_verdict.json — structured verdict.

Representative excerpts from bundle/logs/reproduction_steps.log:

[attempt] 4.16.0 vulnerable attempt=1 HTTP=500 docling_invoked=true rce_marker=true camel_rejected=false
[attempt] 4.16.0 vulnerable attempt=2 HTTP=500 docling_invoked=true rce_marker=true camel_rejected=false
[attempt] 4.18.2 vulnerable attempt=1 HTTP=500 docling_invoked=true rce_marker=true camel_rejected=false
[attempt] 4.18.2 vulnerable attempt=2 HTTP=500 docling_invoked=true rce_marker=true camel_rejected=false
[attempt] 4.18.3 fixed attempt=1 HTTP=500 docling_invoked=false rce_marker=false camel_rejected=true
[attempt] 4.18.3 fixed attempt=2 HTTP=500 docling_invoked=false rce_marker=false camel_rejected=true

Representative marker evidence:

PRUVA_RCE_CONFIRMED version=4.16.0 attempt=1 uid=1000
PRUVA_RCE_CONFIRMED version=4.18.2 attempt=1 uid=1000

Representative fixed rejection:

Custom argument '--pruva-rce-command-b64' is not a recognized docling CLI flag. Only known docling flags are permitted as custom arguments.

Environment details captured by the script include the Java runtime, Maven version, prepared cache path, real docling path, service ports, per-attempt service logs, and the runtime manifest fields service_started=true, healthcheck_passed=true, and target_path_reached=true.

Recommendations / Next Steps

• Upgrade Apache Camel to 4.18.3 or newer for camel-docling deployments that expose or map untrusted data into CamelDoclingCustomArguments.
• Keep strict allowlisting for custom docling flags. Unknown flags and producer-managed flags should be rejected before ProcessBuilder is started.
• Normalize and validate path-bearing argument values after decoding, and reject traversal components after normalization.
• Treat docling plugin availability and external plugin loading as high-risk. Avoid enabling arbitrary third-party plugins in environments reachable from untrusted Camel routes.
• Add regression tests covering:
  • Unknown custom flags.
  • Producer-managed flags such as output path controls.
  • Extension/plugin-specific option names.
  • Path traversal values.
  • Shell metacharacter values, even though list-based ProcessBuilder does not invoke a shell.

Additional Notes

• The reproduction script was run successfully multiple times, including two consecutive clean runs after the final classification patch.
• The primary proof uses the real Camel route and the real docling CLI. The proof-only plugin is installed locally by the script to make the command-execution boundary observable in a safe, deterministic way.
• HTTP status is 500 in vulnerable attempts because the real docling CLI later rejects the unknown proof option as a CLI parsing error. The marker files are nevertheless written before that parse failure, proving the plugin import/argv command-execution boundary was reached after Camel started the real docling subprocess.
• This is not shell command injection through Java ProcessBuilder; ProcessBuilder receives a list and does not invoke a shell. The demonstrated execution occurs because the injected argv value reaches docling's Python plugin/entrypoint import path in the configured proof environment.