CVE-2026-40047: Verified Repro With Script Download

• 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.

Fix Coverage / Assumptions

The original fix relies on the invariant that attacker-controlled custom docling CLI input enters through CamelDoclingCustomArguments and is therefore mediated by validateCustomArguments() before ProcessBuilder.start().

The fixed path explicitly covers:

• DoclingProducer.addCustomArguments(...), which reads CamelDoclingCustomArguments.
• DoclingProducer.validateCustomArguments(...), which rejects null arguments, shell metacharacters, producer-managed flags, unknown long/short flags, and path traversal in custom-argument values.
• DoclingProducer.validateLongFlag(...) / validateShortFlag(...), which implement the allowlist behavior.
• DoclingProducer.validatePathSafety(...), which rejects literal ../ / ..\ and normalized path components named .. for arguments that pass through the custom-argument validator.

The fix does not cover the separate output-path header path:

• DoclingProducer.addOutputDirectoryArguments(...) reads CamelDoclingOutputFilePath and appends --output plus the header value directly to the command list.
• In 4.18.3 and 4.21.0 bytecode, no call to validatePathSafety(...) occurs in addOutputDirectoryArguments(...) before the value is supplied to ProcessBuilder.

The Apache Camel security documentation confirms that the Camel PMC treats trust boundaries and route/operator responsibility as part of security triage, but it also lists CVE-2026-40047 as an accepted Camel-Docling issue for argument injection and path traversal in DoclingProducer. This variant uses the same accepted trust model as the parent: a route maps externally influenced HTTP data into a Camel docling control header.

Variant / Alternate Trigger

The bypass path is a path-bearing header rather than the parent custom-argument header.

Exact runtime entry point tested:

• HTTP endpoint: GET /convert
• Attacker-controlled input: HTTP header X-Out: ../escaped-output
• Route behavior: the harness joins a configured safe base directory with X-Out and sets CamelDoclingOutputFilePath to <safe-output>/../escaped-output.
• Sink: DoclingProducer.addOutputDirectoryArguments(...) appends --output <safe-output>/../escaped-output to the list passed to new ProcessBuilder(command).start().

Relevant code path:

• org.apache.camel.component.docling.DoclingProducer.buildDoclingCommand(...)
• org.apache.camel.component.docling.DoclingProducer.addCustomArguments(...) / validateCustomArguments(...) for the fixed parent path
• org.apache.camel.component.docling.DoclingProducer.addOutputDirectoryArguments(...) for the bypass path
• Evidence bytecode dumps: bundle/logs/vuln_variant/javap_docling_4.18.3.txt and bundle/logs/vuln_variant/javap_docling_4.21.0.txt

The script also sends a control request with args=--pruva-unknown-flag on fixed lines. That control is rejected with the expected allowlist error, proving that the fixed custom-argument validator is active while the output-header path remains reachable.

• Affected versions tested:
  • Affected control: Apache Camel / camel-docling 4.18.2
  • Fixed bypass target: Apache Camel / camel-docling 4.18.3
  • Latest-tested bypass target: Apache Camel / camel-docling 4.21.0
• Risk level and consequences: The reproduced impact is path traversal in the docling --output value after crossing an HTTP-to-Camel route boundary. In the proof harness, a docling executable writes a marker outside the intended SAFE_OUTPUT_DIR. In a real deployment, the consequence depends on the installed docling CLI behavior and filesystem permissions, but it can redirect generated output to unintended directories.

Impact Parity

• Disclosed/claimed maximum impact for parent: argument injection / path traversal, with the repro-stage proof also demonstrating a plugin-mediated code-execution boundary effect for custom arguments.
• Reproduced impact from this variant run: path traversal through CamelDoclingOutputFilePath on fixed 4.18.3 and latest-tested 4.21.0.
• Parity: partial. The variant reproduces the path-traversal portion of the parent root cause on fixed releases, but it does not reproduce plugin-mediated code execution.
• Not demonstrated: arbitrary code execution, shell metacharacter command injection, or arbitrary file overwrite beyond the controlled marker written by the proof docling executable.

Root Cause

The same underlying defect is incomplete validation at the boundary between Camel exchange headers and the external docling CLI argv. The fix added strong validation for CamelDoclingCustomArguments, but validation was not applied uniformly to all attacker-influenceable argv contributors.

In fixed 4.18.3, validateCustomArguments(...) calls validatePathSafety(...) for non-flag custom values and for long-flag values after =, while addOutputDirectoryArguments(...) directly appends the CamelDoclingOutputFilePath header value:

--output <CamelDoclingOutputFilePath>

The fixed/latest bytecode evidence shows addOutputDirectoryArguments(...) reading CamelDoclingOutputFilePath and adding the value to the command list without normalization or traversal rejection. The tested Apache Camel tag identities were resolved as:

• camel-4.18.2: 3864c200f46aa055a0714a069c702c433aca7097
• camel-4.18.3: 6cc2920f7fd0dc642162aca00288f8dc0c9e37de
• camel-4.21.0: a84c468557bba6d400fb9675351d7efe64ce01b4

The exact source fix commit was not identified separately from release tags during this run.

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh from any directory.
2. The script builds a small Camel/Jetty harness under bundle/vuln_variant/harness_output_header, creates a safe output directory, and installs a deterministic proof docling executable under bundle/vuln_variant/bin.
3. It tests three versions side by side:
   • 4.18.2 vulnerable control
   • 4.18.3 fixed target
   • 4.21.0 latest-tested target
4. For each version, it sends:
   • A custom-argument control request (args=--pruva-unknown-flag) to show the fixed allowlist behavior on 4.18.3+.
   • The variant request (GET /convert with X-Out: ../escaped-output) to map the traversal value into CamelDoclingOutputFilePath.
5. Expected bypass evidence: on 4.18.3 and 4.21.0, the docling invocation log contains --output <safe-output>/../escaped-output, and a marker is written in <attempt>/escaped-output, outside <attempt>/safe-output.

Evidence

Key artifacts:

• bundle/logs/vuln_variant/reproduction_steps.log
• bundle/logs/vuln_variant/fixed_4.18.3_docling_invocations.log
• bundle/logs/vuln_variant/fixed_4.18.3_escaped_marker.txt
• bundle/logs/vuln_variant/fixed_4.18.3_custom_args_control_response.txt
• bundle/logs/vuln_variant/latest_4.21.0_docling_invocations.log
• bundle/logs/vuln_variant/latest_4.21.0_escaped_marker.txt
• bundle/vuln_variant/runtime_manifest.json

Representative successful bypass excerpt from reproduction_steps.log:

[attempt] fixed_4.18.3 http=500 invoked=true escaped_marker=true control_http=500 control_rejected=true
[attempt] latest_4.21.0 http=500 invoked=true escaped_marker=true control_http=500 control_rejected=true
[result] BYPASS REPRODUCED: CamelDoclingOutputFilePath traversal reaches docling on fixed/latest version(s).

Representative fixed-version argv evidence:

ARGV[3]=--output
ARGV[4]=.../attempt_fixed_4.18.3/safe-output/../escaped-output
NORMALIZED_OUTPUT=.../attempt_fixed_4.18.3/escaped-output

Representative marker evidence:

PRUVA_OUTPUT_HEADER_TRAVERSAL_REACHED
raw_output=.../safe-output/../escaped-output
normalized_output=.../escaped-output

Representative fixed custom-argument control evidence:

java.lang.IllegalArgumentException: Custom argument '--pruva-unknown-flag' is not a recognized docling CLI flag. Only known docling flags are permitted as custom arguments.

Environment details captured include Java version, Maven version, tested Camel release identities, service logs, per-version docling argv logs, and marker files.

Recommendations / Next Steps

• Apply the same path-normalization and traversal rejection used for custom argument values to CamelDoclingOutputFilePath before adding it to the command list.
• Validate every path-bearing docling exchange header at the point where it is converted into CLI argv, not only values supplied through CamelDoclingCustomArguments.
• Consider resolving output paths against an explicitly configured safe base directory and rejecting any normalized path that escapes that base.
• Add regression tests for:
  • CamelDoclingOutputFilePath containing ../, ..//, and normalized traversal.
  • Fixed custom-argument rejection and output-header rejection in the same test case.
  • Any other docling path-bearing headers that are appended to ProcessBuilder arguments.

Additional Notes

• The reproduction script was run twice consecutively after final edits; both runs completed and reproduced the bypass with exit code 0.
• HTTP status is 500 in the output-header attempts because the Camel/docling harness later fails while processing the proof output format. This does not affect the bypass proof: the docling executable was started by ProcessBuilder, received the unsafe --output value, normalized it outside the safe directory, and wrote the marker.
• The proof docling executable is a deterministic local stand-in for the external CLI. It does not invoke a shell and only writes a marker under the run bundle.