CVE-2026-66907 in Camel
Summary
by MITRE • 08/24/2026
Relative path traversal vulnerability in Apache Camel Google Storage 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-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + "/${file:name}". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket 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. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink 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, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
A critical relative path traversal vulnerability exists within the Apache Camel Google Storage 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 object names within a consumed Google Cloud Storage bucket to write or overwrite arbitrary files on the local filesystem where the Camel process is executing. The vulnerability stems from how the consumer handles the downloadFileName option, which is intended to specify the destination directory for downloaded objects but fails to enforce strict path containment boundaries when processing remote file names.
The technical root cause lies in the construction of the local destination path during object downloads. When the downloadFileName option is configured without an expression token, the component constructs the target file path by concatenating the provided folder or filename with the remote object name using a forward slash separator. This operation utilizes the ${file:name} expression token to retrieve the file-name header from the exchange. Unlike the ${file:onlyname} token which applies canonicalization via FileUtil.stripPath to remove directory traversal sequences, ${file:name returns the value verbatim without any lexical normalization or sanitization. Consequently if a Google Cloud Storage object name contains parent-directory segments such as ..../ etc., these characters are preserved in the final path string and passed directly to the Java File constructor and subsequent blob download operations.
Google Cloud Storage treats object names as opaque UTF-8 keys with no server-side canonicalization, meaning that forward slashes serve only as display conventions for pseudo-directories rather than enforcing structural constraints on the key itself. This design allows an attacker to craft object names containing path traversal sequences that survive round-tripping intact through the storage service and into the Camel consumer logic. Since the filter option is not applied by default unless explicitly configured, there are no initial restrictions on which objects trigger exchanges or downloads. The resulting file path resolution occurs without checking whether the destination remains within the intended download directory boundary, effectively bypassing any implicit security expectations associated with the configuration parameter.
The operational impact of this vulnerability extends beyond simple data integrity loss for files within the designated download folder. Because the process writes to arbitrary locations on the filesystem with the privileges of the Camel application user an attacker could overwrite critical system configuration files replace executable binaries or inject malicious content into sensitive directories such as web roots or home directories depending on deployment context. This capability enables privilege escalation and potential remote code execution if the overwritten file is subsequently executed by a higher-privileged process or service account associated with the environment. The lack of security markers on the downloadFileName parameter further exacerbates risk by providing no indication to developers that this input vector requires rigorous validation against path traversal attacks.
This defect represents an inconsistency within Apache Camel's broader ecosystem where other file-download consumers such as camel-file, camel-ftp, camel-smb, and various Azure Storage implementations have already implemented robust path-segment boundary checks to constrain local downloads strictly to configured directories. The Google Storage component remained the sole object-store download sink lacking this protective measure until recently addressed in later patches. From a classification perspective this vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory and maps to MITRE ATT&CK techniques involving file system discovery and persistence through arbitrary file write capabilities which facilitate long-term access within compromised environments.
To mitigate this risk organizations should immediately upgrade Apache Camel to version 4.22.0 or apply specific patch versions depending on the current release stream such as 4.18.4 for users on the 4.18.x branch and 4.14.9 for those maintaining LTS compatibility with the 4.14.x series. For deployments unable to upgrade immediately a temporary mitigation involves configuring the filter option with a regular expression that restricts accepted object names to simple single-segment identifiers thereby excluding any name containing path separators or parent-directory segments before an exchange is created. It must be noted that no filtering occurs when this option remains unset and expressions are matched against the entire object name string rather than individual components.
An alternative defensive strategy involves modifying the downloadFileName configuration to use explicit expression tokens like ${file:onlyname} instead of relying on implicit behavior with ${file:name}. This approach ensures that remote path information is stripped before constructing local paths although developers must recognize that using expressions in this manner shifts responsibility for security onto route-author-controlled logic rather than benefiting from automated containment checks added in subsequent fixes. Ultimately treating all object names derived from externally writable buckets as untrusted input and avoiding direct derivation of local filesystem paths from such data remains the most robust defense-in-depth practice to prevent similar traversal-based attacks across diverse integration scenarios.