Description
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.
Published: 2026-08-24
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: Arbitrary file overwrite via path traversal
Action: Immediate Patch
AI Analysis

Impact

The consumer of the Camel‑Google‑Storage component constructs a local download path by concatenating the configured downloadFileName option with the remote object name without any lexical normalization or containment check. Because the object name is used verbatim, an attacker able to influence which objects are present in the bucket can cause Camel to write files outside the intended directory. This flaw can lead to arbitrary file overwrite or leakage of sensitive data on the host running the Camel process, and may further allow privilege escalation if critical system files are affected. The weakness corresponds to CWE‑23, relative path traversal.

Affected Systems

Apache Software Foundation’s Apache Camel is affected. The bug exists in Camel Google Storage consumer versions 4.0.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.9. Users of any of those releases must check their exact version. The fixed versions are 4.14.9, 4.18.4, 4.22.0 and newer.

Risk and Exploitability

EPSS score is < 1% and the issue is not listed in CISA KEV. The likely attack vector is an attacker who can add objects to the monitored bucket with a name containing path traversal characters; this inference is based on the consumer listing the bucket and using each object’s name verbatim to build a local path. Because the flaw allows writing to arbitrary file paths when the attacker can control the bucket contents, the potential for high impact is significant, especially if the Camel process runs with elevated privileges. The CVSS score is 7.5. The risk assessment points to a low likelihood of exploitation in environments where an attacker has the ability to influence the bucket contents.

Generated by OpenCVE AI on August 26, 2026 at 04:14 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update Apache Camel to at least version 4.22.0, or to 4.14.9 for the 4.14.x LTS stream, or to 4.18.4 for the 4.18.x stream, to apply the containment check added in the fix.
  • If an upgrade cannot be performed immediately, set the filter option to a regex that matches only single‑segment object names to prevent creation of exchanges for path‑containing keys.
  • Alternatively, configure downloadFileName using an expression that does not include the remote object name, for example with ${file:onlyname}, ensuring the local path does not incorporate the bucket key.
  • Treat all object names coming from the bucket as untrusted input and avoid building local file system paths directly from them; consider running Camel under a restricted user account to limit damage.

Generated by OpenCVE AI on August 26, 2026 at 04:14 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Github GHSA Github GHSA GHSA-f78g-9385-qxqj Apache Camel-Google-Storage: the consumer appended the remote object name to the configured downloadFileName directory without constraining the result
History

Thu, 27 Aug 2026 18:00:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*

Tue, 25 Aug 2026 20:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'}

ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Mon, 24 Aug 2026 20:30:00 +0000

Type Values Removed Values Added
References

Mon, 24 Aug 2026 18:00:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache camel
Vendors & Products Apache
Apache camel

Mon, 24 Aug 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title Apache Camel: Camel-Google-Storage: the consumer appended the remote object name to the configured downloadFileName directory without constraining the result
Weaknesses CWE-23
References

Subscriptions

Apache Camel
cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-08-25T19:37:45.023Z

Reserved: 2026-07-28T09:28:37.811Z

Link: CVE-2026-66907

cve-icon Vulnrichment

Updated: 2026-08-24T19:13:39.604Z

cve-icon NVD

Status : Analyzed

Published: 2026-08-24T17:18:06.330

Modified: 2026-08-27T20:35:51.997

Link: CVE-2026-66907

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-26T04:15:04Z

Weaknesses
  • CWE-23

    Relative Path Traversal