CVE-2026-40047: Apache Camel Docling Argument Injection Enables OS Command Execution

Executive Summary

A critical argument injection vulnerability (CVE-2026-40047) has been identified in the camel-docling component of Apache Camel, the widely used enterprise integration framework. The DoclingProducer class assembles command-line arguments for the external docling document-processing tool and launches it via java.lang.ProcessBuilder. A weak denylist-based validation mechanism can be bypassed, allowing attackers to inject arbitrary CLI arguments — and in certain configurations achieve OS-level command execution on the Camel host.

CVSS Score: 9.1 (Critical) CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

The vulnerability affects Apache Camel 4.15.0 through 4.18.2. Fixed versions are 4.18.3 (LTS branch) and 4.19.0 (mainline).

Vulnerability Overview

Affected Versions

Technical Analysis

The camel-docling component integrates Apache Camel routes with the docling external CLI tool for document processing (PDF conversion, OCR, etc.). The DoclingProducer class builds the argument list and invokes the tool using java.lang.ProcessBuilder — which uses list-based invocation (not a shell), meaning traditional shell metacharacter injection (; | &) is not directly possible.

However, the weak denylist validation allowed two attack vectors:

Attack Vector 1: Arbitrary CLI Argument Injection

CamelDoclingCustomArguments header (List<String>) → DoclingProducer argument list
 
Denylist only rejected a small set of explicitly named flags.
Any unblocked flag name or value was passed directly to ProcessBuilder.
 
Attacker supplies: ["--output-dir", "/tmp/attacker/", "--model", "attacker_model"]
Result: docling writes output to attacker-controlled path, loads attacker model

Attack Vector 2: Directory Traversal via Path Values

The denylist only rejected values containing the literal string "../"
 
Bypasses:
  - URL-encoded: "..%2F"
  - Symlink chains
  - Unicode canonicalization variants
 
Result: Docling resolves paths outside the intended working directory

Cascading Impact

While ProcessBuilder list-form prevents direct shell injection, the injected arguments can:

• Override output directories → write processed files to attacker-chosen paths
• Specify attacker-controlled model paths → potential for model-loading exploits
• Exfiltrate documents → redirect output to attacker-accessible network shares
• Achieve code execution → if docling supports plugin/extension arguments pointing to attacker-supplied code

Patch Changes (4.18.3 / 4.19.0)

The fix replaces the weak denylist with three changes:

Affected Component: camel-docling

The camel-docling component is part of the Apache Camel ecosystem for document intelligence workflows. Routes using this component are identified by:

// Camel DSL — vulnerable usage pattern
from("direct:process-doc")
  .to("docling:convert?outputFormat=markdown");
 
// Vulnerable header — CamelDoclingCustomArguments
// Any route that maps untrusted message content to this header is exploitable
exchange.getIn().setHeader("CamelDoclingCustomArguments", 
    untrustedUserInput);  // ← VULNERABLE

Remediation

Step 1: Upgrade Apache Camel

<!-- Maven — update to fixed version in pom.xml -->
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-docling</artifactId>
    <version>4.18.3</version>  <!-- LTS fix -->
    <!-- OR 4.19.0 for mainline -->
</dependency>
 
<!-- Verify the camel-docling version in your dependency tree -->
<!-- mvn dependency:tree | grep camel-docling -->

// Gradle — update build.gradle
implementation 'org.apache.camel:camel-docling:4.18.3'

Step 2: Audit Custom Argument Usage (Immediate)

Search your Camel routes for any usage of CamelDoclingCustomArguments that maps external input:

# Find usages in Java/XML routes
grep -r "CamelDoclingCustomArguments\|DoclingCustomArguments" src/
 
# Find Camel XML DSL routes
grep -r "docling" src/ --include="*.xml" --include="*.yaml"

Step 3: Input Validation at Route Level

Until upgrade is applied, add a strict allowlist for any CamelDoclingCustomArguments header values at the route level:

// Defensive sanitization before camel-docling (defense-in-depth)
from("direct:process")
  .process(exchange -> {
      List<String> args = exchange.getIn().getHeader(
          "CamelDoclingCustomArguments", List.class);
      if (args != null) {
          // Remove ALL custom args from untrusted sources
          exchange.getIn().removeHeader("CamelDoclingCustomArguments");
      }
  })
  .to("docling:convert");

Detection Indicators

Post-Remediation Steps

1. Upgrade to Apache Camel 4.18.3 (LTS) or 4.19.0+ (mainline)
2. Audit all Camel routes using camel-docling for external input mapped to CamelDoclingCustomArguments
3. Review docling output directories for unexpected files written during the exposure window
4. Apply principle of least privilege — run the Camel host with minimal filesystem permissions
5. Monitor process spawn logs for unexpected docling invocation arguments

References

• NIST NVD — CVE-2026-40047
• Apache Camel Security
• Apache Camel Downloads

Related Reading

• CVE-2026-24013: Apache IoTDB Authentication Bypass via Forged Session ID
• CVE-2026-24014: Apache IoTDB DataNode Path Traversal