EUVD-2026-64958
GHSA-f78g-9385-qxqj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAttacker uploads traversal-named object to consumed GCS bucket
-
DeliveryCamel consumer polls bucket and iterates blob names verbatim
-
ExploitdownloadFileName expression appends raw object name via ${file:name}
-
ExecutionResolved path escapes configured download directory
-
PersistCamel writes blob content to attacker-chosen filesystem location
-
ImpactArbitrary file overwrite at Camel process privilege
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Relative path traversal prevention
|
| Exploitation Conditions | Exploitation requires all of the following: (1) the camel-google-storage consumer is deployed with the downloadFileName option explicitly set - routes that omit this option are not affected; (2) the filter option is not configured, which is the default, meaning no object-name restriction is in place; (3) an attacker can influence the names of objects present in the consumed GCS bucket, for example by uploading objects to a bucket with non-restrictive ACLs, exploiting a compromised upstream process, or operating in a multi-tenant environment with shared bucket access. The vulnerability is limited to integrity - the Camel process writes content to an attacker-chosen path; confidentiality is not directly compromised. The defect is consumer-only and does not affect the Google Storage producer. Routes consuming buckets where all object names are fully operator-controlled and no external party can create or rename objects are not at meaningful risk. |
| Impact | The provided CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) records a high confidentiality impact with no integrity impact, which is inconsistent with the described write-primitive vulnerability - the actual effect is an arbitrary file write, an integrity impact, not a confidentiality disclosure. This metric discrepancy should be verified with the NVD or Apache; the assessed vector in this report corrects it to I:H/C:N. Real-world risk is gated by a meaningful exploitation condition: an attacker must control or influence GCS object names in the specific bucket the Camel route consumes. For routes consuming buckets with open or shared write access (external partner uploads, public buckets), this represents a genuine threat; for buckets strictly controlled by the Camel operator, risk is considerably lower. EPSS of 0.20% at the 9th percentile is consistent with no observed exploitation. SSVC confirms exploitation status as none but marks the flaw automatable - once malicious object names are present in the bucket, no further attacker interaction is required. Technical impact is rated partial by SSVC. No KEV listing and no public POC have been identified; this is a lower-urgency but architecturally meaningful finding for affected deployments. |
| Exploit ScenarioDerived | An attacker with write access to a GCS bucket consumed by a Camel route - such as an external partner, a compromised upstream service, or a misconfigured bucket policy - uploads an object whose name contains traversal segments, for example ../../etc/cron.d/backdoor. When the Camel consumer polls the bucket with downloadFileName set and no filter configured, it evaluates the unsanitized path, resolves it outside the download directory, and writes the object's content to the attacker-chosen location with the privileges of the Camel JVM process. No public POC has been identified, but the attack is automatable once malicious object names are in place. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Aug 25, 2026
Arbitrary file write via path traversal in the Apache Camel Google Cloud Storage consumer component affects versions 4.0.0 through 4.21.x, allowing anyone who can influence GCS bucket object names to cause the Camel process to create or overwrite files outside the configured download directory. The consumer appends blob names verbatim to the local path using the unsanitized ${file:name} token without directory containment checks, and the filter option that could restrict object names is disabled by default. No public exploit is identified at time of analysis; SSVC rates the flaw automatable once malicious object names are present in the consumed bucket, and vendor-released patches are available at 4.14.9, 4.18.4, and 4.22.0.
Earlier versions of this analysis (1)
Relative path traversal in the Apache Camel Google Storage consumer allows anyone with write access to a consumed GCS bucket to cause the Camel process to create or overwrite files at arbitrary locations on the host filesystem. The vulnerability exists because the consumer builds local file destinations using the ${file:name} expression token, which returns GCS object names verbatim without path normalization, and performs no boundary check to confirm the resolved path stays inside the configured downloadFileName directory. Affected deployments span Apache Camel 4.0.0 through pre-4.22.0 where the camel-google-storage component is used with the downloadFileName consumer option; no public exploit code has been identified at time of analysis, though the attack primitive is straightforward.
RemediationAI
Vendor-released patches: 4.14.9 for users on the 4.14.x LTS stream, 4.18.4 for users on the 4.18.x stream, and 4.22.0 for all other affected versions. Full upgrade guidance is published at https://camel.apache.org/security/CVE-2026-66907.html. For deployments that cannot upgrade immediately, two compensating controls are available. First, set the filter option on the camel-google-storage consumer to a regular expression that accepts only simple single-segment object names - for example, a pattern that rejects any name containing a forward slash or parent-directory sequence - noting that without this option no filtering occurs at all and that the expression is matched against the entire object name. Second, configure downloadFileName to use an expression built on ${file:onlyname} rather than the implicit ${file:name} token; be aware that when downloadFileName contains any expression token it is treated as route-author-controlled and is not protected by the containment check introduced in the fix, so this approach removes the verbatim path propagation but places trust in the route author's expression. As defense in depth, treat all object names in any externally writable GCS bucket as untrusted input and avoid deriving local filesystem paths from them.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is the camel-google-storage consumer in Apache Camel (CPE: cpe:2.3:a:apache_software_foundation:apache_camel:*:*:*:*:*:*:*:*). When the downloadFileName option is set, the consumer evaluates the expression downloadFileName + "/${file:name}", where ${file:name} returns the Exchange file-name header derived verbatim from blob.getBlobId().getName() without path sanitization. Unlike ${file:onlyname}, which calls FileUtil.stripPath to remove directory components, ${file:name} preserves the raw object key including any forward slashes and parent-directory sequences. The root cause (CWE-23, Relative Path Traversal) is that the resulting path string is passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no boundary check confirming the resolved path remains within the configured directory. Google Cloud Storage object names are opaque UTF-8 keys stored and returned exactly as written - forward slashes are a display convention only and parent-directory segments survive round-tripping intact through the GCS API. The filter option that could restrict consumed object names to safe patterns is not applied unless explicitly configured; by default no filtering occurs. Other Camel download consumers (camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files, and Azure Storage download paths) already implement path-segment boundary checks; camel-google-storage was the remaining gap.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Attack originates via GCS bucket upload requiring no Camel-system privileges (PR:N); actual impact is arbitrary file write (I:H), not confidentiality disclosure, correcting the provided C:H/I:N vector.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4DescriptionCVE.org
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.
Blast Radius
ecosystem impact- 7 maven packages depend on org.apache.camel:camel-google-storage (5 direct, 2 indirect)
Ecosystem-wide dependent count for version 4.0.0.
Executive ViewAI
Apache Camel versions 4.0.0 through 4.21.x contain a path traversal vulnerability in the Google Cloud Storage consumer component that allows arbitrary file write and overwrite operations outside the intended download directory. Organizations using affected versions risk unauthorized data modification, service disruption, and potential lateral movement through compromised file writes. Immediate patch deployment to version 4.14.9, 4.18.4, or 4.22.0 is required to eliminate this exposure.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate
Exploit-DB