Skip to main content
Public proof of conceptFix available

CVE-2026-40047

A public proof of concept exists; no exploitation attested.

  • Published2026-07-06
  • Fixed in4.18.3
  • WeaknessCWE-88

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

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.

Timeline

dates in UTC
  1. 2026-07-0609:16CVE publishedNVD

Versions per branch

NVD · OSV
Apache camel
BranchAffectedFixed in
4.x≥ 4.15.0, < 4.18.34.18.3

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Products declared by the CNA1 product

As apache, the CNA that assigned this CVE, declared them in the CVE record; versions as written.

  • Apache Software Foundation Apache Camelother versions: not affected

    package org.apache.camel:camel-doclinghttps://repo.maven.apache.org/maven2

    Affected
    • ≥ 4.15.0, < 4.18.3fixed in 4.18.3semver

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2026-07-06

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Vendor advisories

  • CVE-2026-40047 Red Hat Product Security2 known affected

    camel-docling: Apache Camel Docling: CLI argument injection and path traversal

    camel-docling as a component of Red Hat build of Apache Camel 4 for Quarkus 3 · camel-docling as a component of Red Hat build of Apache Camel for Spring Boot 4

Full record on NVD

Fix

  1. Update Apache camel to 4.18.3
  2. Workaround from the vendor Red Hat Product Security CVE-2026-40047 · 2 productsFor deployments that cannot upgrade immediately, strip the CamelDoclingCustomArguments header from inbound HTTP messages before the docling producer (for example removeHeaders('CamelDocling*') at the start of the route). Additionally, restrict HTTP endpoint access with authentication.
  3. No fix available, says the vendor Red Hat Product Security CVE-2026-40047 · 2 productsFix deferred

Advisories and patches

Detection

read 2026-11-01 01:02 UTC
Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof of concept
Metasploit modules
none listed
Metasploit Framework

Sources

Identifiers

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Published
2026-07-06
Last Modified
2026-10-25
NVD status
Analyzed
GitHub Advisory
GHSA-rpv3-6645-2vqc

Frequently asked questions

What is CVE-2026-40047?

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.

Is CVE-2026-40047 actively exploited?

Active exploitation of CVE-2026-40047 has not been confirmed. Its EPSS score was 2.4% on 2026-11-08, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-40047?

CVE-2026-40047 has a CVSS v3 base score of 9.1 (CRITICAL severity), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.

Running camel-docling? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, November 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record