Apache Camel Docling CVE-2026-95629

Exploitation requires the camel-docling component running in the default CLI mode (the docling-serve mode does not use this header), and a deployment where the CamelDoclingOutputFilePath header can be populated from values originating outside the deployment - specifically a Camel route that forwards externally-influenced data into that header, or a consumer that maps incoming message headers WITHOUT Camel's default header filtering. What LIMITS exploitation: Camel's default HeaderFilterStrategy, used by the JMS and Kafka consumers, strips Camel-namespace headers (including this one) from inbound messages, so default-filtered consumers are not exposed; the attacker also does not control the output file's exact byte content (only the converted form of a supplied document) and cannot confine or redirect naming beyond directory choice. Affected version streams are 4.15.0-before-4.18.5 and 4.19.0-before-4.22.2; the 4.15.x-4.17.x and 4.19.x-4.21.x lines are end-of-life and unpatched. Note that after upgrading, the new outputBaseDirectory endpoint option is unset by default and must be explicitly set to fully confine the header.

This is a medium-severity path-traversal/arbitrary-write issue whose real-world risk is genuinely moderate-to-low, not an emergency. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L = 5.4) is internally consistent with the description: network-reachable, requires some privilege (PR:L, consistent with needing to influence a Camel header), no user interaction, unchanged scope, no confidentiality loss, and only partial integrity and availability impact because the attacker controls where a file lands but not its exact byte content. The priority signals reinforce the modest rating: there is no CISA KEV listing, no EPSS score was supplied, and the vuln.today Decision label is 'awaiting_data' - i.e., no act_now/emergency determination. No SSVC decision values were provided. No public exploit was identified at time of analysis; the references are vendor advisories, a JIRA ticket, and the fix pull requests, not exploit code. The most important caveat is that exploitation is conditional, not default: it requires a route that forwards externally-influenced values into the CamelDoclingOutputFilePath header, because Camel's default HeaderFilterStrategy (used by the JMS and Kafka consumers) strips Camel-namespace headers from inbound messages. So the PR:L/AV:N signals, while accurate for an attacker who can reach that header, overstate exposure for the common case where default header filtering is in place - this is best read as a defense-in-depth hardening fix for specific route designs rather than a broadly exploitable remote flaw.

An application runs a Camel route that maps or copies incoming (e.g. HTTP or custom-transport) message headers into the exchange without Camel's default header filtering, allowing an external party's value to populate the CamelDoclingOutputFilePath header. The attacker sets that header to an absolute path or one containing '..' segments, and the DoclingProducer passes it verbatim to the docling '--output' flag, causing the converted document (Markdown/HTML/JSON/text named after the input) to be written into any directory the Camel process can write to. No public exploit code was identified at time of analysis, and the attacker influences only where the file is written and, indirectly, its converted content - not its exact bytes.