CVE-2026-66906 in Camel
Summary
by MITRE • 08/24/2026
Relative path traversal vulnerability in Apache Camel Azure Storage Blob component.
This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.
The camel-azure-storage-blob component can download an Azure Storage blob to the local filesystem through its downloadBlobToFile operation, writing into the directory named by the fileDir endpoint option, which is documented as usable from both the producer and the consumer. BlobOperations.downloadBlobToFile built the local target by joining fileDir with the remote blob name exactly as the Azure SDK reported it (new File(fileDir, client.getBlobName())) and passed the result straight to the SDK download call, with no lexical normalization and no check that the resolved location stayed inside fileDir. The blob name is not route-controlled data: the consumer enumerates the container in BlobConsumer.createBatchExchangesFromContainer, which lists blobs and creates one exchange per entry from BlobItem.getName() verbatim, applying no name filtering by default. A blob name containing parent-directory segments therefore resolved to a location outside the configured fileDir, letting anyone able to influence the names present in the consumed container cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. Azure Storage blob containers use a flat namespace in which the blob name is an opaque key, so a name carrying such segments is stored and listed as given. The fileDir option is an ordinary common-group configuration parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp and camel-azure-files - already constrained their local downloads to the configured directory using a path-segment boundary check; the camel-azure-storage-blob download path was not covered by that work.
Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, constrain the names the consumer will act on using the regex endpoint option, which is applied to each listed blob name as a full-string match, so that only simple single-segment names are accepted and any name carrying a path separator or a parent-directory segment is filtered out before an exchange is created; the prefix option can additionally narrow the listing server-side, noting that when both are set regex takes priority and prefix is ignored. Alternatively, avoid the downloadBlobToFile operation on untrusted containers and write the payload from the route under a file name the route itself controls, rather than one taken from the remote listing. As defence in depth, treat the blob names in any externally writable container as untrusted input and do not derive local filesystem paths from them.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
A critical relative path traversal vulnerability exists within the Apache Camel Azure Storage Blob component, specifically affecting versions 4.0.0 through 4.18.4 across multiple release streams including 4.14.x LTS and 4.19.0 to 4.22.0 prior to patching. This flaw allows an attacker who can influence the names of blobs within a consumed Azure Storage container to write files outside the intended local directory, potentially leading to arbitrary file overwrite with the privileges of the Camel process. The vulnerability stems from how the component handles the mapping of remote blob identifiers to local filesystem paths during download operations.
The technical root cause lies in the implementation of the BlobOperations.downloadBlobToFile method and the associated consumer logic. When downloading a blob, the system constructs the target file path by concatenating the configured fileDir endpoint option with the remote blob name obtained directly from Azure SDK calls without any lexical normalization or containment verification. Specifically, the code uses new File(fileDir, client.getBlobName()) to determine the destination. Because this operation does not resolve symbolic links or normalize parent-directory sequences such as .. before checking boundaries, a blob named ../../etc/passwd will result in a file path that escapes the designated download directory and writes directly into system directories like /etc if permissions allow.
The attack surface is significantly expanded by the default behavior of the BlobConsumer component. In its createBatchExchangesFromContainer method, the consumer enumerates all blobs within a specified container and creates an exchange for each entry using the blob name verbatim from BlobItem.getName(). There is no inherent filtering or validation applied to these names before they are processed as part of the route data flow. Since Azure Storage utilizes a flat namespace where blob keys are opaque strings, there is nothing in the storage service itself that prevents naming objects with path traversal characters. Consequently, any user or process capable of uploading blobs to an accessible container can trigger this vulnerability simply by creating files with maliciously crafted names containing relative path sequences.
The operational impact of this flaw extends beyond simple data integrity issues within the application's working directory. By overwriting arbitrary files on the host system, an attacker could compromise critical configuration files, inject malicious scripts into executable directories, or overwrite log files to hide tracks of intrusion. In environments where the Camel process runs with elevated privileges, such as root or a service account with broad write access, this vulnerability can lead to full system compromise. This represents a classic path traversal scenario mapped to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which allows unauthorized access to files and directories that should be restricted.
This specific implementation gap highlights an inconsistency in Apache Camel's security posture across its various file transport components. Other consumers such as camel-file, camel-ftp, camel-smb, camel-mina-sftp, and camel-azure-files had previously implemented path-segment boundary checks to ensure downloads remained within the configured directory. The azure-storage-blob component was inadvertently excluded from these hardening efforts, leaving it vulnerable while its peers were protected. This discrepancy underscores the importance of consistent security controls across all modules in a complex framework like Apache Camel.
To mitigate this risk immediately, users are strongly advised to upgrade their Apache Camel dependencies to version 4.22.0 or later, which includes the necessary fixes for path validation and normalization. For organizations operating on long-term support streams that cannot yet migrate to the latest release, upgrading to version 4.18.4 is recommended for those in the 4.18.x series, while users of the older LTS branch should upgrade to version 4.14.9. These patched versions enforce strict containment boundaries when resolving local file paths from remote blob names.
For deployments that face immediate constraints preventing an upgrade, several defensive measures can be employed within the route configuration. The most effective workaround is to utilize the regex endpoint option on the consumer side. This setting applies a full-string match filter against each listed blob name before creating an exchange. By configuring this regular expression to only accept simple single-segment names without path separators or parent-directory indicators, the application effectively filters out any maliciously crafted filenames at the ingestion point. Additionally, using the prefix option can narrow the server-side listing results, although it is important to note that if both regex and prefix are set, the regex takes priority and the prefix is ignored.
Another mitigation strategy involves altering how data is persisted locally within the route logic. Instead of relying on the downloadBlobToFile operation which uses the remote filename directly, developers should write the payload from the exchange under a file name generated or controlled entirely by the application code itself. This approach decouples the local filesystem path from untrusted external input derived from the Azure container listing. Furthermore, treating all blob names in externally writable containers as untrusted data is essential for defense-in-depth strategies. Security teams should also consider monitoring ATT&CK technique T1564: Host File System Indicator Removal or Obfuscation if they suspect active exploitation attempts aimed at modifying system files to evade detection.