EUVD-2026-64956
GHSA-2x37-89hj-2j95
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain write access to consumed Azure container
-
DeliveryUpload blob named with ../ traversal segments
-
ExploitCamel consumer lists and creates exchange from raw name
-
ExecutiondownloadBlobToFile resolves path outside fileDir
-
PersistOverwrite target file as Camel process
-
ImpactEscalate integrity loss to code execution or disruption
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: (1) a Camel deployment using the camel-azure-storage-blob component with the downloadBlobToFile operation and a configured fileDir on an affected version; (2) the consumer reading a container whose blob names the attacker can influence - i.e. the ability to create/name blobs in that container (a shared, multi-tenant, or externally-fed container); and (3) the default no-filtering configuration, meaning no restrictive regex endpoint option is set (setting a single-segment-only regex blocks the attack). Limiting factors: if the consumed container is writable only by the same trust domain that runs Camel, there is no meaningful attacker; and the impact is scoped to files the Camel process user can write. No end-user interaction and no authentication to Camel itself is needed, but attacker control over container contents is the essential prerequisite. |
| Impact | The signals partially conflict and warrant a nuanced read. The vendor CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) and the SSVC assessment (Exploitation: none, Automatable: yes, Technical Impact: total) both point to a serious, easily-automated issue, yet EPSS is very low (0.18%, 7th percentile) and there is no KEV listing and no known public exploit - consistent with a real but not-yet-exploited weakness rather than an active campaign. The most important caveat is that exploitation is not truly unauthenticated-against-defaults in the way PR:N/AC:L implies: an attacker must be able to place blobs with crafted names into a container that a Camel consumer is already configured to read, so real-world risk concentrates in deployments that consume containers writable by untrusted or lower-trust parties. Where that trust boundary exists, the impact is genuinely high - arbitrary file overwrite as the Camel process can escalate to code execution or service disruption depending on writable paths - so any organization running an affected version with downloadBlobToFile against a shared or externally-fed container should treat patching as a priority; where the consumed container is fully controlled by the same trust domain, the practical risk is much lower. The vendor-rated C:H is also questionable since the operation writes rather than reads (see assessed vector below) - verify impact assumptions against your own deployment. |
| Exploit ScenarioDerived | An attacker with write access to an Azure Storage container that a vulnerable Camel route consumes uploads a blob whose name embeds parent-directory segments (e.g. '../../../opt/app/config/settings.properties'). When the Camel consumer enumerates the container and invokes downloadBlobToFile with no regex filter, the crafted name resolves outside the configured fileDir, causing Camel to overwrite that target file with attacker-supplied content under the Camel process's privileges. No public exploit is identified at time of analysis, but the attack is straightforward and automatable given the low network complexity. |
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 camel-azure-storage-blob component lets an attacker who can influence blob names in a consumed Azure Storage container force Camel to create or overwrite files outside the configured download directory, with the privileges of the Camel process. It affects Apache Camel 4.0.0 before 4.14.9, 4.15.0 before 4.18.4, and 4.19.0 before 4.22.0, where BlobOperations.downloadBlobToFile joined the fileDir option with the raw remote blob name without normalization or containment checks. No public exploit has been identified at time of analysis and the CVSS is 9.1, but EPSS is low (0.18%, 7th percentile), indicating no observed exploitation activity yet.
Earlier versions of this analysis (1)
Path traversal in Apache Camel's camel-azure-storage-blob component allows any party who can influence blob names in a consumed Azure Storage container to write files to arbitrary locations on the filesystem with the privileges of the Camel process. Affected versions span 4.0.0 through pre-4.22.0 across three maintained release streams; fixed releases are 4.14.9, 4.18.4, and 4.22.0. No public exploit code or active exploitation is confirmed at time of analysis, but the arbitrary file-write primitive - exercisable without complexity once container write access is held - makes this a meaningful integrity and potential code-execution risk in any integration scenario where the consumed blob container accepts external uploads.
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.22.0, which fixes the issue; users on the 4.14.x LTS stream should upgrade to 4.14.9 and users on the 4.18.x stream to 4.18.4 (per https://camel.apache.org/security/CVE-2026-66906.html). For deployments that cannot upgrade immediately, constrain the consumer using the regex endpoint option, which is applied as a full-string match to each listed blob name, so only simple single-segment names are accepted and any name containing a path separator or parent-directory segment is filtered out before an exchange is created; the prefix option can additionally narrow the listing server-side, but note that when both are set regex takes priority and prefix is ignored. Alternatively, avoid downloadBlobToFile on untrusted containers entirely and have the route write the payload under a filename the route itself controls rather than one taken from the remote listing. As defense in depth, treat blob names from any externally-writable container as untrusted input and never derive local filesystem paths directly from them; the main trade-off of the regex/prefix controls is that overly strict filters may silently drop legitimately-named blobs.
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
Apache Camel is a Java-based enterprise integration framework, and the affected camel-azure-storage-blob component wraps the Azure Storage Blob SDK to move blobs between Camel routes and Azure. The root cause is CWE-23 (Relative Path Traversal): the downloadBlobToFile operation built its local target as new File(fileDir, client.getBlobName()) and passed it straight to the SDK download call, applying no lexical normalization and no path-segment boundary check to confirm the resolved path stayed inside fileDir. The blob name is attacker-influenceable rather than route-controlled - BlobConsumer.createBatchExchangesFromContainer enumerates the container and creates one exchange per entry from BlobItem.getName() verbatim with no default filtering - and because Azure blob containers use a flat namespace where the name is an opaque key, a name embedding '../' segments is stored and listed as given, resolving to a location outside the intended directory. Notably, Camel's other download consumers (camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files) already enforced a path-segment boundary check; this component was simply omitted from that hardening.
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:H/A:N
Remote attacker influences blob names without authenticating to Camel; impact is arbitrary file write/overwrite (I:H) with no direct read (C:N) or availability (A:N) primitive, diverging from the vendor's C:H.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4DescriptionCVE.org
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.
Executive ViewAI
Apache Camel's Azure Storage Blob component (versions 4.0.0-4.21.x) contains a path traversal vulnerability allowing arbitrary file write with process privileges. This affects organizations using Camel for Azure blob data processing: an attacker capable of controlling blob names in consumed containers could overwrite critical application files, potentially leading to code execution or system compromise.
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