Summary
Apache Camel's SMB remote-file consumer can use a directory-listing name to construct a remote path without normalizing it or verifying that it remains within the configured polling directory. A malicious, compromised, or tampered remote server may therefore cause Camel to read, delete, or rename files outside the intended directory using the endpoint's credentials.
Apache Camel's SMB remote-file consumer can use a directory-listing name to construct a remote path without normalizing it or verifying that it remains within the configured polling directory. A malicious, compromised, or tampered remote server may therefore cause Camel to read, delete, or rename files outside the intended directory using the endpoint's credentials.
Affected context
The issue affects Apache Camel SMB consumers that process names returned by a remote share listing. Risk is present when the listing contains a name with path-segment components rather than a single file name, and when Camel uses the resulting path for retrieval or configured file-disposition operations such as deletion or renaming. The configured starting-directory restriction did not enforce containment for this remote operand.
The issue affects Apache Camel SMB consumers that process names returned by a remote share listing. Risk is present when the listing contains a name with path-segment components rather than a single file name, and when Camel uses the resulting path for retrieval or configured file-disposition operations such as deletion or renaming. The configured starting-directory restriction did not enforce containment for this remote operand.
Exploit preconditions
- Attack surface: Apache Camel SMB remote-file consumer and the remote share's directory-listing response
- Required access: No direct Camel credentials are necessarily required for an on-path attacker able to alter an unauthenticated listing channel; alternatively, a compromised, malicious, or unusual remote server may provide the listing
- Trigger point: Processing a listed entry during consumer polling
- Required configuration: Retrieval is reachable through normal consumer operation; deletion or renaming additionally requires options such as
delete,move,preMove,moveFailed, or rename-based read locking - Why exploitation is possible: The reported name is concatenated into the remote path without lexical normalization or a containment check against the configured polling directory
- Attack surface: Apache Camel SMB remote-file consumer and the remote share's directory-listing response
- Required access: No direct Camel credentials are necessarily required for an on-path attacker able to alter an unauthenticated listing channel; alternatively, a compromised, malicious, or unusual remote server may provide the listing
- Trigger point: Processing a listed entry during consumer polling
- Required configuration: Retrieval is reachable through normal consumer operation; deletion or renaming additionally requires options such as
delete,move,preMove,moveFailed, or rename-based read locking - Why exploitation is possible: The reported name is concatenated into the remote path without lexical normalization or a containment check against the configured polling directory
Why this happens
The underlying bug is an incomplete path-boundary validation pattern. Camel treated a remote directory-listing name as a trusted single path segment, concatenated it with the configured directory, and used the result for subsequent remote operations without canonicalizing it or verifying that the resolved path remained inside the intended directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, because attacker-influenced path components could escape the configured location.
The underlying bug is an incomplete path-boundary validation pattern. Camel treated a remote directory-listing name as a trusted single path segment, concatenated it with the configured directory, and used the result for subsequent remote operations without canonicalizing it or verifying that the resolved path remained inside the intended directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, because attacker-influenced path components could escape the configured location.
Potential impact
- Camel may read files outside the configured polling directory.
- Camel may delete files outside the intended directory when deletion is enabled.
- Camel may rename or move files outside the intended directory under applicable route settings.
- Sensitive remote data may be disclosed through downstream processing.
- Files or workflows may be disrupted, altered, or removed using the endpoint's credentials.
- The broader server account boundary may be affected if the remote service does not confine that account.
- Camel may read files outside the configured polling directory.
- Camel may delete files outside the intended directory when deletion is enabled.
- Camel may rename or move files outside the intended directory under applicable route settings.
- Sensitive remote data may be disclosed through downstream processing.
- Files or workflows may be disrupted, altered, or removed using the endpoint's credentials.
- The broader server account boundary may be affected if the remote service does not confine that account.
General mitigation guidance
Mitigation generally requires treating every remote listing name as untrusted path input and enforcing the directory boundary for every remote operation.
Common defensive patterns include:
- Normalize or canonicalize the candidate path before use.
- Verify that the resolved path remains beneath the configured polling directory using component-aware containment checks.
- Reject names containing unexpected separators, parent-directory components, or other non-segment syntax when only file names are expected.
- Apply the same containment validation consistently to retrieval, deletion, moves, failed moves, and read-lock renames.
- Keep remote accounts restricted to the minimum share and filesystem permissions required by the route.
- Prefer authenticated and integrity-protected transport for directory listings where supported.
- Use secure, supported maintenance releases containing the vendor's path-containment correction.
Mitigation generally requires treating every remote listing name as untrusted path input and enforcing the directory boundary for every remote operation.
Common defensive patterns include:
- Normalize or canonicalize the candidate path before use.
- Verify that the resolved path remains beneath the configured polling directory using component-aware containment checks.
- Reject names containing unexpected separators, parent-directory components, or other non-segment syntax when only file names are expected.
- Apply the same containment validation consistently to retrieval, deletion, moves, failed moves, and read-lock renames.
- Keep remote accounts restricted to the minimum share and filesystem permissions required by the route.
- Prefer authenticated and integrity-protected transport for directory listings where supported.
- Use secure, supported maintenance releases containing the vendor's path-containment correction.
How teams detect issues like this
Detection can combine source analysis, configuration review, and runtime monitoring:
- Search for remote path construction that concatenates a configured directory with listing-controlled names.
- Flag file operations that use unnormalized or unvalidated paths from FTP, SFTP, SMB, or similar directory listings.
- During code review, verify that containment checks cover every operation, not only local downloads or initial retrieval.
- Test policy rules for path separators, parent-directory components, absolute paths, and alternate path syntax in remote listing entries.
- Review routes that enable deletion, moving, failed-moving, or rename-based read locks because these increase the impact of an escape.
- Monitor remote file-operation logs for accesses outside expected directory prefixes and for unusual delete or rename targets.
- Automated static-analysis and dependency-review tools may help identify vulnerable path-handling patterns and unsupported component versions.
Detection can combine source analysis, configuration review, and runtime monitoring:
- Search for remote path construction that concatenates a configured directory with listing-controlled names.
- Flag file operations that use unnormalized or unvalidated paths from FTP, SFTP, SMB, or similar directory listings.
- During code review, verify that containment checks cover every operation, not only local downloads or initial retrieval.
- Test policy rules for path separators, parent-directory components, absolute paths, and alternate path syntax in remote listing entries.
- Review routes that enable deletion, moving, failed-moving, or rename-based read locks because these increase the impact of an escape.
- Monitor remote file-operation logs for accesses outside expected directory prefixes and for unusual delete or rename targets.
- Automated static-analysis and dependency-review tools may help identify vulnerable path-handling patterns and unsupported component versions.
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/ |
