EUVD-2026-104216
GHSA-pw2m-67gx-9wx2
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain on-path or malicious-server control of directory listing
-
DeliveryReturn crafted listing entry with '../' segments
-
ExploitCamel concatenates name without normalization
-
ExecutionConsumer resolves path outside polling directory
-
ImpactRead/delete/rename file using endpoint credentials
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path canonicalization, traversal prevention
MITRE ATT&CK
2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a Camel remote-file consumer (azure-files, or the FTP/SFTP consumers sharing the RemoteFileConsumer base class) actively polling a remote directory - retrieval is reachable in the DEFAULT consumer configuration because consumers download every listed file. The attacker must be able to control the directory-listing name returned by the server: an on-path attacker on the FTP control channel (which has no integrity protection) can rewrite a LIST response without credentials, or a compromised, malicious, multi-tenant, or virtual-filesystem-backed server can emit the crafted name directly. For deletion or renaming (versus mere read), the route must additionally set a disposition option - delete=true, move, preMove, moveFailed, or readLock=rename - all described as common. KEY LIMITING FACTORS: for the azure-files scheme named in this CVE, the Azure Files REST service does not normally return multi-segment listing names, so triggering it there is impractical; the jailStartingDirectory option (enabled by default) did NOT constrain this remote operand before the fix, so it offered no protection; and the required listing-control position is a non-trivial prerequisite reflected in AC:H. |
| Impact | The official CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4 HIGH) is internally coherent with the described mechanism: exploitation is remote and requires no Camel-side credentials (PR:N), but hinges on an attacker-controllable condition - either an on-path position on the integrity-free FTP control channel, or a compromised/malicious/multi-tenant/virtual-filesystem server that emits a crafted listing name - which correctly justifies AC:H. No EPSS score, KEV listing, or POC was provided; the vendor advisory itself states the azure-files exposure was 'corrected on the same basis as the other remote-file consumers rather than from a demonstrated proof of concept,' so there is no public exploit identified at time of analysis. A critical nuance specific to THIS CVE: it covers the azure-files scheme, and the advisory notes the Azure Files REST service 'does not normally return' multi-segment listing names, making practical exploitation of this particular component substantially harder than the raw 7.4 suggests - this is largely a defense-in-depth hardening of an inherited base-class flaw rather than a demonstrated attack against azure-files. The more exploitable instances of the same root cause live in the FTP/SFTP consumers. Net: a real but not urgent issue - no evidence of active or widespread exploitation, elevated complexity, and a narrow trigger condition for the named component. Treat as a patch-on-schedule item, prioritizing FTP/SFTP Camel deployments over azure-files-only ones. |
| Exploit ScenarioDerived | An organization runs an Apache Camel route whose azure-files (or FTP/SFTP) consumer polls a remote directory and downloads every listed file using the endpoint's credentials. An attacker who can influence the directory-listing response - by sitting on-path on the unencrypted FTP control channel or by controlling a malicious/multi-tenant backing server - returns an entry such as '../../secret.txt' instead of a plain filename. Camel concatenates this verbatim without normalization or containment checks, so it reads (and, if delete/move/readLock=rename disposition options are set, deletes or renames) files outside the configured polling directory; no public exploit code exists and the attack requires the privileged listing-control position (AC:H). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Path traversal in Apache Camel's remote-file consumers - the azure-files scheme named in this CVE plus the FTP/SFTP consumers sharing the RemoteFileConsumer base class - lets a malicious, compromised, or multi-tenant remote file server (or an on-path attacker on the integrity-free FTP control channel) cause Camel to read, delete, or rename files outside the directory it was configured to poll, using the endpoint's own credentials. Retrieval is reachable in the default consumer configuration because remote consumers download every listed file; deletion and renaming additionally require delete=true, move, preMove, moveFailed, or readLock=rename. The jailStartingDirectory option, enabled by default and documented as a boundary, did not constrain this remote operand before the fix, so it offered no protection; triggering the traversal requires control over a listing name returned by the server, and for azure-files specifically the Azure Files REST service does not normally return multi-segment names, making exploitation there impractical. No public exploit code or confirmed active exploitation was identified at time of analysis; vendor patches are available.
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.23.0; users on the 4.22.x stream should upgrade to 4.22.1 and users on the 4.18.x LTS stream to 4.18.5, while anyone still on the end-of-life 4.14.x stream must move to a supported stream. The fix is delivered through upstream PRs 25730, 25745, 25746, and 25747 (see https://camel.apache.org/security/CVE-2026-79986.html and https://issues.apache.org/jira/browse/CAMEL-24487). Because jailStartingDirectory did not constrain the remote operand before the fix, no simple configuration toggle removes the exposure on unpatched versions; compensating controls must instead address the untrusted listing source. Where possible, replace plain FTP with FTPS or SFTP so the control channel is integrity-protected and an on-path attacker can no longer rewrite LIST responses (trade-off: requires server-side TLS/SSH support and certificate or host-key management, and does not help against a genuinely compromised or malicious server). Point remote-file consumers only at single-tenant, trusted servers, since a shared or virtual-filesystem-backed server can emit crafted names directly (trade-off: architectural change, not feasible for multi-tenant integrations). Finally, remove delete=true, move, preMove, moveFailed, and readLock=rename from affected routes so that a traversal can at worst cause out-of-directory reads rather than deletion or renaming of files outside the polled directory (trade-off: loses post-processing and exclusive-read semantics that some routes depend on).
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). Camel's remote-file consumers poll a directory on a remote server and build each file's absolute remote path by concatenating the configured directory with the file name reported in the server's directory listing - a plain string concatenation via FtpUtils.absoluteFilePath and GenericFileConsumer with no lexical normalization and no containment check on the result. That unvalidated path then becomes the operand for every subsequent remote operation: 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, so a listing entry that is not a single path segment (e.g. one containing ../) resolved outside the polled directory. Crucially the listing name is not route-controlled data - it is supplied by the remote server, and the FTP control channel carries no integrity protection, so an on-path attacker can rewrite a LIST response without holding any credentials. The same surface had already been closed on the local side when the localWorkDirectory download path was constrained against parent-directory segments; this CVE is the remote half. The upstream fix adds an isWithinStartingDirectory() strategy to GenericFileConsumer consulted when jailStartingDirectory is enabled, plus a separator-aware GenericFileHelper.isWithinDirectory() that compacts paths and rejects targets that still resolve upwards, with remote callers passing '/' rather than the platform separator.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Remote and unauthenticated (AV:N/PR:N), but AC:H because the attacker must hold an on-path position or control the listing server; C:H/I:H for read plus delete/rename of out-of-directory files, A:N as no service-availability loss is described.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
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.
Executive ViewAI
Apache Camel's remote-file consumers (azure-files, FTP, and SFTP) contain a high-severity path traversal flaw that can let a malicious, compromised, or multi-tenant remote file server-or an on-path attacker on the FTP control channel-use the application's own credentials to read, delete, or rename files outside the configured polling directory. Organizations relying on these consumers for third-party or multi-tenant file exchange face potential data exposure and integrity loss, especially where delete=true, move, preMove, moveFailed, or readLock=rename are enabled. Leadership should prioritize remediation because the flaw undermines the documented jailStartingDirectory boundary and can turn trusted file-ingestion pipelines into a credential-enabled path to broader filesystem access.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate
Exploit-DB