WaratekVRT Sign in

CVE-2026-95629 Apache Camel

Affected softwareApache Camel
Severity5.4 Medium CVSS 3.1
WeaknessPath traversal (CWE-22)
Published26 Oct 2026
Updated6 Nov 2026

Published 19 days ago. NVD often adds the list of affected products days or weeks after a CVE is published, and the other sources we check lag too. The scope and status here may change.

Description

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.

Exploitation status

No public exploit

No exploit has been reported in the sources we check. The 1 repository below are public GitHub repositories with fewer than 5 stars.

  • CISA KEV not listed
  • VulnCheck KEV not listed
  • CISA Vulnrichment exploitation: none
  • Indexed PoC 1 indexed, none at 5+ stars
  • EPSS 1.0% chance in 30 days

1 of these are GitHub repositories with fewer than 5 stars. They are listed for reference and don't count toward the exploitation status above.

IndexArtifactStarsFirst seen
GitHub PoC Reproducer for CVE-2026-95629 — Apache Camel camel-docling passed the CamelDoclingOutputFilePath header to docling's --output verbatim (CWE-22). Camel Spring Boot + Camel Quarkus. 2026-10-29

Waratek protection

Protected by Waratek

Waratek has a rule that blocks attacks on this vulnerability.

Decided by A vulnerability class already blocked by an ARMR security rule
Finding Protected by Waratek's ARMR path-traversal security rule, which blocks this class of attack at the JVM level without a rule written for this CVE specifically. The CVE's weakness is CWE-22: Path Traversal.
Candidate fix https://github.com/apache/camel/pull/26737 : a pull request: the change under review

How to mitigate CVE-2026-95629

Apply the vendor's fix for Apache Camel. Until you can, Waratek RASP blocks exploitation with its path traversal rule. It runs inside the Java application, with no code changes.

Waratek RASP Runtime protection for Java applications

Affected software and releases

Products and versions

1 product, 2 version entries
SourceVendorProductSchemeAffected versions
nvd apache camel generic ≥ 4.15.0 and < 4.18.5 · ≥ 4.19.0 and < 4.22.2

References

URLTags
https://github.com/apache/camel/pull/26737 pr
https://camel.apache.org/security/CVE-2026-40047.html Not Applicable
https://camel.apache.org/security/CVE-2026-78163.html Not Applicable
https://camel.apache.org/security/CVE-2026-95629.html Vendor Advisory
https://github.com/apache/camel/pull/27362 Issue Tracking, Patch
https://github.com/apache/camel/pull/27365 Issue Tracking
https://issues.apache.org/jira/browse/CAMEL-24894 Issue Tracking, Vendor Advisory

Timeline

Published2026-10-26By the CVE Program.
NVD record modified2026-11-06NVD's own last-modified date for this record.