Apache Camel Docling CVE-2026-95628

Exploitation requires camel-docling running in CLI mode (the default, and the only mode that passes custom arguments to docling) and an attacker able to control the contents of the CamelDoclingCustomArguments header - specifically supplying an absolute path (e.g. to the allowlisted --artifacts-path flag), in either the separate 'flag value' or attached 'flag=value' form, which the pre-fix validatePathSafety accepted because it only rejected ../ sequences and normalized paths retaining a .. element. The key limiting factor is reachability of that header: it belongs to the Camel header namespace, which default header filtering removes (the JMS and Kafka consumers strip it), so the flaw is only reachable where a route explicitly forwards externally-influenced values into the header or where a consumer maps incoming headers without that default filtering. Additional limits: PR:L means some privilege/position to influence the message is needed, impact is confined to directories the Camel process can already access, and the 4.15.x-4.17.x and 4.19.x-4.21.x lines are end-of-life and will not be fixed.

This is a medium-severity (CVSS 3.1 5.4, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) path-traversal flaw in the Apache Camel camel-docling component, assessed as an incomplete fix of CVE-2026-40047. The signals point to limited real-world urgency rather than an emergency. The vuln.today Decision label is 'awaiting_data', and there is no CISA KEV listing, so this is not confirmed as actively exploited. No EPSS score was supplied in the input, so exploitation probability cannot be quantified from the data. The references consist of the vendor advisory, a JIRA issue, and three GitHub pull requests - these are remediation artifacts, not exploit code, so no public exploit has been identified at time of analysis. The CVSS vector claims AV:N and PR:L, but the description materially constrains reachability: exploitation requires that an attacker-influenced value actually reach the CamelDoclingCustomArguments header, which lives in the Camel header namespace that default header filtering (as used by the JMS and Kafka consumers) strips from incoming messages. The network vector is therefore only realistic where a route deliberately forwards external input into that header or a consumer maps incoming headers without the default filter - a routing/configuration dependency the raw CVSS score does not capture. The impact is bounded: C:N/I:L/A:L reflects that an attacker can redirect the docling subprocess to a different directory (e.g. via the allowlisted --artifacts-path flag) that the Camel process can access, not full code execution or confidentiality loss. Net: a real defect worth patching on a normal cadence, but the combination of medium severity, required privileges, configuration-dependent reachability, awaiting_data priority, and absence of KEV/EPSS/PoC argues against treating it as a high-priority emergency.

In a Camel deployment running camel-docling in the default CLI mode, a route forwards an externally-influenced value into the CamelDoclingCustomArguments header (or a consumer maps incoming headers without Camel's default header filtering). An attacker who can shape that value supplies an absolute path to an allowlisted path-valued flag such as --artifacts-path, and because validatePathSafety only rejected relative traversal and never absolute paths, the value passes unchanged and the docling process is pointed at an arbitrary directory the Camel process can access. No public exploit code was identified in the provided references.