criticalCVE-2026-40047

CVE-2026-40047 camel vulnerability

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache Camel Docling component. 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. This issue affects Apache Camel: from 4.15.0 before 4.18.3. Users are recommended to upgrade to a release that contains the CAMEL-23212 fix. On the mainline the fix is included from Apache Camel 4.19.0 (and later releases such as 4.20.0). For users on the 4.18.x LTS releases stream, upgrade to 4.18.3. The fix replaces the denylist with a strict allowlist of recognized `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.

Productcamel
CVSS9.1
EPSS0.01569
UpdatedJuly 13, 2026

Quick answer

apache camel should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.

Who is affected

Affected versions

  • Review vendor advisory for affected versions.

Fixed versions

  • Apply the latest vendor-supported patched version.

How to fix it

CVE-2026-40047 affects Apache Camel Docling. Upgrade Apache Camel on the deployed branch to 4.18.3 and review any route that exposes this component to user-controlled messages, headers, files, or backend responses. Affected ranges in the local record are 4.15.0 through before 4.18.3.

  1. Inventory every service, route, integration runtime, container image, and dependency lockfile that includes Apache Camel Docling or related Camel modules.
  2. Compare deployed Camel versions with the affected ranges for CVE-2026-40047; prioritize internet-facing routes, message brokers, file parsers, and integrations that process untrusted input.
  3. Upgrade to 4.18.3, or to a later vendor-supported Camel release on the same branch.
  4. Rebuild application artifacts and container images from a clean dependency lockfile so vulnerable Camel modules are removed from direct and transitive dependencies.
  5. Harden route boundaries by filtering user-controlled Camel headers, component control headers, serialized objects, command arguments, paths, and backend response bodies before they reach Camel internals.
  6. Rotate credentials, tokens, queue secrets, and integration keys if the affected route could expose data, redirect backend requests, deserialize attacker-controlled objects, or execute unintended operations.
  7. Deploy first to staging, run regression tests for the impacted route, then promote to production with monitoring for route errors, deserialization events, SSRF indicators, unexpected command arguments, and authorization failures.

Scan now. Google sign-in is only needed to unlock fix guidance.

Verify the fix

  • Confirm dependency output shows Apache Camel 4.18.3 or a later fixed release in every affected application.
  • Replay malicious or unexpected headers, serialized payloads, paths, files, command arguments, and backend responses against the affected route and verify they are rejected or sanitized.
  • Check application logs after deployment for exceptions, leaked stack traces, SSRF attempts, command execution anomalies, unauthorized backend operations, or unexpected route destinations.
  • Open the generated Fixnx page and confirm the canonical URL ends with camel-cve-2026-40047.
  • Re-run sitemap validation and confirm camel-cve-2026-40047 appears once in sitemap.xml with the full CVE-2026-40047 suffix.

Related categories

Trusted references

FAQ

What is affected by CVE-2026-40047?

apache camel should be checked against the vendor advisory and trusted references linked on this page.

What should I fix first?

Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.

How do I confirm the fix worked?

Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.

How are Fixnx security risk categories chosen?

Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.