Summary
Apache Camel's FTP-based remote-file consumers can accept path components from a remote directory listing without confirming that the resulting path remains within the configured polling directory. A malicious, compromised, or tampered server may therefore cause Camel to retrieve, delete, or rename files outside the intended directory using the endpoint's credentials.
Apache Camel's FTP-based remote-file consumers can accept path components from a remote directory listing without confirming that the resulting path remains within the configured polling directory. A malicious, compromised, or tampered server may therefore cause Camel to retrieve, delete, or rename files outside the intended directory using the endpoint's credentials.
Affected context
The vulnerability occurs in Apache Camel FTP, FTPS, and SFTP remote-file consumers when a server-supplied listing entry is combined with the configured polling directory and used as a remote operation path. The affected behavior is relevant when the remote server is malicious, compromised, multi-tenant, backed by a virtual filesystem, or when an attacker can alter an unprotected FTP control-channel response. Retrieval is available in default consumer operation, while deletion and renaming depend on route disposition settings such as delete, move, preMove, moveFailed, or rename-based read locking.
The vulnerability occurs in Apache Camel FTP, FTPS, and SFTP remote-file consumers when a server-supplied listing entry is combined with the configured polling directory and used as a remote operation path. The affected behavior is relevant when the remote server is malicious, compromised, multi-tenant, backed by a virtual filesystem, or when an attacker can alter an unprotected FTP control-channel response. Retrieval is available in default consumer operation, while deletion and renaming depend on route disposition settings such as delete, move, preMove, moveFailed, or rename-based read locking.
Exploit preconditions
- Attack surface: Apache Camel remote-file consumer endpoints using FTP, FTPS, or SFTP.
- Required access: Ability to influence the remote server's directory listing, directly or through server compromise, malicious administration, virtualization, or an on-path alteration of an unprotected FTP control channel.
- Trigger point: Processing a directory listing entry during polling and subsequent retrieval, deletion, or rename operations.
- Why exploitation is possible: The reported name is concatenated with the configured directory without lexical normalization or containment validation, allowing the resulting operand to resolve outside the intended polling directory.
- Attack surface: Apache Camel remote-file consumer endpoints using FTP, FTPS, or SFTP.
- Required access: Ability to influence the remote server's directory listing, directly or through server compromise, malicious administration, virtualization, or an on-path alteration of an unprotected FTP control channel.
- Trigger point: Processing a directory listing entry during polling and subsequent retrieval, deletion, or rename operations.
- Why exploitation is possible: The reported name is concatenated with the configured directory without lexical normalization or containment validation, allowing the resulting operand to resolve outside the intended polling directory.
Why this happens
The underlying bug is an insufficient pathname containment check, mapped to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. Camel trusted a remote listing name as a path component, constructed an absolute remote path through string concatenation, and used that path for later file operations without normalizing it and verifying that it remained beneath the configured directory. Although related local download handling enforced containment for the local work directory, the corresponding remote operation path lacked the same boundary enforcement.
The underlying bug is an insufficient pathname containment check, mapped to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. Camel trusted a remote listing name as a path component, constructed an absolute remote path through string concatenation, and used that path for later file operations without normalizing it and verifying that it remained beneath the configured directory. Although related local download handling enforced containment for the local work directory, the corresponding remote operation path lacked the same boundary enforcement.
Potential impact
- Camel may retrieve files outside the configured polling directory.
- Camel may delete files outside the intended directory when deletion is enabled.
- Camel may rename or move unintended remote files when disposition or locking options permit it.
- Sensitive remote file contents may be exposed to the application or downstream processing.
- Files may be modified, removed, or displaced using the endpoint account's permissions.
- The effective impact may extend to the remote account boundary if the server does not confine that account.
- Camel may retrieve files outside the configured polling directory.
- Camel may delete files outside the intended directory when deletion is enabled.
- Camel may rename or move unintended remote files when disposition or locking options permit it.
- Sensitive remote file contents may be exposed to the application or downstream processing.
- Files may be modified, removed, or displaced using the endpoint account's permissions.
- The effective impact may extend to the remote account boundary if the server does not confine that account.
General mitigation guidance
Mitigation generally centers on treating every server-supplied listing name as untrusted and enforcing directory boundaries at the point where remote operation paths are created.
Common defensive patterns include:
- Normalize and validate remote paths before retrieval, deletion, or renaming.
- Require verified containment beneath the configured polling directory for every remote operation.
- Prefer APIs that represent directory and file names separately rather than accepting unrestricted path strings.
- Reduce trust in remote listings and use authenticated, integrity-protected transport where supported.
- Apply least privilege to endpoint credentials and constrain remote accounts to dedicated directories.
- Disable unnecessary deletion, movement, and rename behaviors when they are not required.
- Keep local work-directory containment controls enabled and enforce equivalent checks on remote operands.
Mitigation generally centers on treating every server-supplied listing name as untrusted and enforcing directory boundaries at the point where remote operation paths are created.
Common defensive patterns include:
- Normalize and validate remote paths before retrieval, deletion, or renaming.
- Require verified containment beneath the configured polling directory for every remote operation.
- Prefer APIs that represent directory and file names separately rather than accepting unrestricted path strings.
- Reduce trust in remote listings and use authenticated, integrity-protected transport where supported.
- Apply least privilege to endpoint credentials and constrain remote accounts to dedicated directories.
- Disable unnecessary deletion, movement, and rename behaviors when they are not required.
- Keep local work-directory containment controls enabled and enforce equivalent checks on remote operands.
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis rules identifying path construction by concatenating configured directories with remote or external names.
- Code review checks for missing normalization, canonicalization, or containment validation before file operations.
- Tests using directory-listing names containing parent-directory components and other multi-segment forms.
- Runtime monitoring for remote operations targeting paths outside an endpoint's configured directory.
- Policy enforcement requiring integrity-protected transport, least-privilege file accounts, and explicit path-boundary validation.
- Automated security review tools that flag externally controlled path values flowing into retrieval, deletion, rename, or move APIs.
Organizations can look for this weakness through:
- Static analysis rules identifying path construction by concatenating configured directories with remote or external names.
- Code review checks for missing normalization, canonicalization, or containment validation before file operations.
- Tests using directory-listing names containing parent-directory components and other multi-segment forms.
- Runtime monitoring for remote operations targeting paths outside an endpoint's configured directory.
- Policy enforcement requiring integrity-protected transport, least-privilege file accounts, and explicit path-boundary validation.
- Automated security review tools that flag externally controlled path values flowing into retrieval, deletion, rename, or move APIs.
Sources
| Source | Link |
|---|---|
| camel. | camel.apache.org/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| issues. | issues.apache.org/ |
| github. | github.com/ |
