--- id: CVE-2026-95629 title: >- Apache Camel: Camel-Docling Unvalidated Output Path Header Enables Writing Conversion Output to an Arbitrary Directory summary: >- Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer … severity: medium cvss: 5.4 cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L' cvssSource: cna cwe: - CWE-22 vendor: Apache Software Foundation product: 'org.apache.camel:camel-docling' affected: - 'org.apache.camel:camel-docling >= 4.15.0 < 4.18.5' - 'org.apache.camel:camel-docling >= 4.19.0 < 4.22.2' published: '2026-10-26' updated: '2026-10-26' sourceUpdated: '2026-10-26T08:44:22.849Z' source: CVEORG sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-95629' references: - url: 'https://camel.apache.org/security/CVE-2026-95629.html' label: Apache Camel Security Advisory - CVE-2026-95629 - url: 'https://issues.apache.org/jira/browse/CAMEL-24894' label: CAMEL-24894 - url: 'https://github.com/apache/camel/pull/26737' label: >- Fix on main, released in 4.23.0 (commit 48485d408f190c46ef408ba4ba75e45b4e8ffb04) - url: 'https://github.com/apache/camel/pull/27365' label: >- Backport to camel-4.22.x for 4.22.2 (commit 4f8eb14999163523af6b77d08bfd1b9e79ee49c0) - url: 'https://github.com/apache/camel/pull/27362' label: >- Backport to camel-4.18.x, released in 4.18.5 (commit 54552df4b9e512cb2025fad22b88429ef0e0169c) - url: 'https://camel.apache.org/security/CVE-2026-40047.html' label: >- CVE-2026-40047, whose custom-argument validation directs callers to the header described here - url: 'https://camel.apache.org/security/CVE-2026-78163.html' label: >- CVE-2026-78163, whose fix introduced the inputBaseDirectory option that outputBaseDirectory mirrors tags: - cve.org ingestedAt: '2026-10-26T09:22:35.522Z' --- ## Overview Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory. ## Affected - `org.apache.camel:camel-docling >= 4.15.0 < 4.18.5` - `org.apache.camel:camel-docling >= 4.19.0 < 4.22.2` ## Remediation Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The CamelDoclingOutputFilePath header is now normalized before it reaches docling, and a new outputBaseDirectory endpoint option confines it: when the option is set, a value that resolves outside that directory, including an absolute path, is rejected with an IOException before docling is started. The option is unset by default, so it must be set after upgrading wherever the header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. ### Workarounds Do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory.