Severity:
CVSS 3.1: 5.9 (medium) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Affected versions:
- Apache Camel (org.apache.camel:camel-docling) 4.15.0 before 4.18.5
- Apache Camel (org.apache.camel:camel-docling) 4.19.0 before 4.22.1
- Apache Camel (org.apache.camel:camel-docling) 4.18.5 unaffected
- Apache Camel (org.apache.camel:camel-docling) 4.22.1 unaffected
- Apache Camel (org.apache.camel:camel-docling) 4.23.0 unaffected
Description:
Server-Side Request Forgery (SSRF), Improper Limitation of a Pathname to a
Restricted Directory ('Path Traversal') and Exposure of Sensitive Information
to an Unauthorized Actor 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.1.
DoclingProducer decided what a String message body meant by inspecting its
prefix. A body starting with http:// or https:// was handed to Docling as a
remote URL to fetch, a body starting with / or containing a backslash was read
from the local filesystem, and anything else was written to a temporary file
and converted as document content. The mode was chosen implicitly and no
endpoint option allowed a route author to pin the component to a single
interpretation, so a route that means convert whatever text arrives in the body
silently became a fetcher of remote resources or a reader of local files
whenever the text happened to begin with one of those prefixes. The only guard
applied to the derived value was a size check, and that check was wrapped in an
existence test, so a path that resolved to nothing, or to a pseudo-file
reporting a size of zero, passed without being checked at all. Five call sites
reached the two sinks: the CLI mode appended the value as the final positional
argument of the docling subprocess, and the docling-serve mode passed it either
to HttpSource for the backend to fetch or to Files.readAllBytes so that the
content could be base64-encoded and uploaded. Because the exchange body is
never filtered by a HeaderFilterStrategy, unlike the Camel header namespace, a
sender able to place text in a message that a route forwards into a docling
endpoint could reach both sinks without any opt-in from the deployment.
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.1. If users are on the 4.18.x releases stream, then they are suggested to
upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life
before this issue was resolved and will not receive a fix, so deployments on
those lines must move to a supported release. For deployments that cannot
upgrade immediately, do not route message bodies that originate outside the
deployment into a docling endpoint, and pass the document through a typed body
such as File, byte[] or InputStream, or through the CamelDoclingInputFilePath
header, so that the body is never subject to prefix interpretation.
Solution:
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x
stream should upgrade to 4.22.1 and users on the 4.18.x stream should upgrade
to 4.18.5. The 4.14.x stream and earlier reached end of life before this issue
was resolved and will not receive a fix.
Work Arounds:
Do not route message bodies originating outside the deployment into a docling
endpoint. Pass the document through a typed body such as File, byte[] or
InputStream, or through the CamelDoclingInputFilePath header, so that the body
is not subject to prefix interpretation.
Credit:
Li Zhiyao (BUPT) (finder)
Andrea Cosentino (remediation developer)
References:
https://camel.apache.org/security/CVE-2026-78163.html
https://issues.apache.org/jira/browse/CAMEL-24422
https://github.com/apache/camel/pull/25596
https://github.com/apache/camel/pull/25733
https://github.com/apache/camel/pull/25744
https://camel.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-78163
