Description
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Azure Files 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 azure-files scheme. Its consumer derives from the same RemoteFileConsumer base class and composed the remote path through a plain concatenation helper, so it inherited the same unconstrained resolution. Reaching it requires a listing name that is not a single path segment, which the Azure Files REST service does not normally return; the exposure was corrected on the same basis as the other remote-file consumers rather than from a demonstrated proof of concept against this scheme.



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.
Published: 2026-10-19
Score: 7.4 High
EPSS: n/a
KEV: No
Impact: Path Traversal that can read, delete, or rename files outside the configured polling directory.
Action: Immediate Patch
AI Analysis

Impact

This vulnerability arises because the Camel Azure Files component concatenates the configured polling directory with filenames returned in a server's LIST output without normalizing or validating containment. If a listing entry contains traversal segments, it resolves to a path outside the intended directory, allowing the component to read, delete, or rename remote files that it otherwise could not access. The weakness is a classic Path Traversal (CWE‑22) and permits an attacker who can influence the directory listing—such as a compromised or malicious server—to access or modify files beyond the operator's boundary, thereby violating confidentiality, integrity, and availability of the storage account.

Affected Systems

The affected product is Apache Camel. Versions from 4.0.0 up to 4.18.4, and from 4.19.0 up to 4.22.0, are vulnerable. Users on the 4.18.x LTS stream should upgrade to 4.18.5, users on the 4.22.x releases stream should upgrade to 4.22.1, and all users should migrate to 4.23.0 or newer, which contains the fix.

Risk and Exploitability

The CVSS score is 7.4, indicating a high severity vulnerability. The EPSS score is not available, and the vulnerability is not listed in CISA's KEV catalog. Exploitation requires an attacker or a compromised server to include path‑traversal segments in a LIST response. Once a traversal name is received, the Camel client will use the endpoint's credentials to perform file operations on arbitrary paths, making the attack vector likely remote and network‑based. Because the component operates with the server‑provided filenames without integrity protection, the risk is significant for deployments that trust remote listings or expose the endpoint to potentially malicious tenants.

Generated by OpenCVE AI on October 19, 2026 at 11:41 UTC.

Remediation

Vendor 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.

Vendor Workaround

For deployments that cannot upgrade immediately, scope the SAS token or account key used by the endpoint to the directory being polled, so that the service enforces the boundary independently of Camel. The HTTPS transport already protects the listing in transit, so the remaining exposure is a share whose contents are written by a party that is not trusted. 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.

OpenCVE Recommended Actions

  • Upgrade to Apache Camel 4.23.0, or at minimum to 4.22.1 for 4.22.x streams and 4.18.5 for 4.18.x LTS streams, to apply the containment check that prevents path traversal.
  • If an upgrade is not immediately possible, restrict the SAS token or account key used by the endpoint to the directory being polled so that the storage service itself enforces the boundary.
  • Restrict the consumer so that it accepts only simple, single‑segment file names by using the filter, antInclude, or include options, and avoid enabling delete, move, preMove, moveFailed, or readLock=rename when pointing to a server that is not fully trusted.
  • Treat all remote file names as untrusted input and apply defensive validation to reject or sanitize unexpected path components.

Generated by OpenCVE AI on October 19, 2026 at 11:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 19 Oct 2026 16:45:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache apache Camel
Apache camel
Vendors & Products Apache
Apache apache Camel
Apache camel

Mon, 19 Oct 2026 10:45:00 +0000

Type Values Removed Values Added
Description Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Azure Files 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 azure-files scheme. Its consumer derives from the same RemoteFileConsumer base class and composed the remote path through a plain concatenation helper, so it inherited the same unconstrained resolution. Reaching it requires a listing name that is not a single path segment, which the Azure Files REST service does not normally return; the exposure was corrected on the same basis as the other remote-file consumers rather than from a demonstrated proof of concept against this scheme. 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.
Title Apache Camel: camel-azure-files resolved the remote path of a polled file from the name reported in the server directory listing without constraining it to the directory being polled, so a listing entry containing traversal segments could be moved outside
Weaknesses CWE-22
References
Metrics cvssV3_1

{'score': 7.4, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N'}

Subscriptions

Apache Apache Camel Camel
cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-10-19T10:25:58.121Z

Reserved: 2026-08-25T16:20:32.604Z

Link: CVE-2026-79986

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-19T11:17:20.860

Modified: 2026-10-19T11:17:20.860

Link: CVE-2026-79986

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-19T16:30:13Z

Weaknesses
  • CWE-22

    Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')