Severity:
CVSS 3.1: 7.4 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Affected versions:
- Apache Camel (org.apache.camel:camel-ftp) 4.0.0 before 4.18.5
- Apache Camel (org.apache.camel:camel-ftp) 4.19.0 before 4.22.1
- Apache Camel (org.apache.camel:camel-ftp) 4.18.5 unaffected
- Apache Camel (org.apache.camel:camel-ftp) 4.22.1 unaffected
- Apache Camel (org.apache.camel:camel-ftp) 4.23.0 unaffected
Description:
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
vulnerability in Apache Camel FTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before
4.22.1.
The Camel remote-file consumers poll a directory on a remote server and build
the absolute remote path of each file by concatenating the configured directory
with the file name reported in the server's directory listing. That
concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no
lexical normalization and no check that the result stayed inside the directory
being polled, and the resulting path became the operand for every subsequent
remote operation on the file: retrieval (FtpOperations.retrieveFile /
SftpOperations, reached from GenericFileConsumer where the retrieve name is
taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true
(GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed
or readLock=rename is configured (GenericFileProcessStrategySupport and
GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched
performed any containment check. A listing entry that is not a single path
segment therefore resolved to a path outside the configured polling directory,
causing Camel to read, delete or rename files outside it using the endpoint's
own credentials. A listing name is not route-controlled data. It is supplied by
the remote server, and the FTP control channel carries no integrity protection
at all, so an on-path attacker can rewrite a LIST response without holding any
credentials; a compromised, malicious or multi-tenant server, or a server
backed by a virtual filesystem, can emit such a name directly. Retrieval is
reachable in a default consumer configuration, since the remote consumers
download every listed file; deletion and renaming additionally require one of
the disposition options above, all of which are common. Escape from the
directory Camel was configured to poll is unconditional, while escape from the
server's own account boundary additionally depends on whether that server
confines the account. The jailStartingDirectory option, which is documented as
restricting Camel to the starting directory and is enabled by default, governed
producer writes and, since the localWorkDirectory containment work, consumer
downloads to the local work directory - but it did not constrain this remote
operand, so its name and description claimed a boundary that was not enforced
here. The same entry point had already been recognised on the local side: the
localWorkDirectory download path was constrained so that a remote file name
containing parent-directory segments could not resolve outside the local work
directory. The remote operand was the remaining half of that surface. This
artifact provides the ftp, ftps and sftp schemes, all of which are affected.
The reporter demonstrated the issue end to end against an ftp endpoint, driving
a Camel route with a malicious server whose LIST response named a file outside
the polled directory.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x
releases stream should upgrade to 4.22.1. Users on the 4.18.x LTS releases
stream should upgrade to 4.18.5. The 4.14.x stream reached end of life and does
not receive this fix; users on it should move to a supported releases stream.
Solution:
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x
releases stream should upgrade to 4.22.1. Users on the 4.18.x LTS releases
stream should upgrade to 4.18.5. The 4.14.x stream reached end of life and does
not receive this fix; users on it should move to a supported releases stream.
The fix adds a separator-aware GenericFileHelper.isWithinDirectory overload,
since remote paths always use a forward slash regardless of the platform Camel
runs on, and a GenericFileConsumer.isWithinStartingDirectory strategy consulted
from isValidFile when jailStartingDirectory is enabled. The base implementation
is a no-op, because names obtained from a local directory listing are always
single path segments; RemoteFileConsumer and SmbConsumer override it to compact
the resolved path and verify on path-segment boundaries that it still resolves
inside the directory being polled. A file resolving outside is skipped and a
warning is logged, rather than raising, so that the remaining legitimate
entries in the same listing still process. Containment was chosen over
stripping the path component because remote directories are legitimately nested
and a parent-directory segment that still resolves back inside the polled
directory remains valid. The check runs after the existing match filters so
that the "." and ".." entries returned by SFTP servers, which the hidden-file
rule already excludes, do not log on every poll. The change adds no new module
dependency.
Work Arounds:
For deployments that cannot upgrade immediately, prefer the encrypted
transports, sftp or ftps rather than ftp, so that a directory listing cannot be
rewritten in transit by an on-path attacker, and verify the server's host key
or certificate. Constrain the consumer with the filter, antInclude or include
options so that only simple single-segment file names are accepted, and avoid
enabling delete=true, move, preMove, moveFailed or readLock=rename on endpoints
pointing at a server whose listing content is not fully trusted, since those
options are what turn the issue from a read into a destructive operation. Where
the server supports it, confine the account used by the endpoint to the polled
directory, so that the server itself enforces the boundary independently of
Camel. As defence in depth, treat file names reported by any remote server
outside the route's trust boundary as untrusted input.
Credit:
Dilrevx, NSSL, SJTU (reporter)
Andrea Cosentino (remediation developer)
References:
https://camel.apache.org/security/CVE-2026-79983.html
https://issues.apache.org/jira/browse/CAMEL-24487
https://github.com/apache/camel/pull/25730
https://github.com/apache/camel/pull/25745
https://github.com/apache/camel/pull/25746
https://github.com/apache/camel/pull/25747
https://camel.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-79983
