Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach or join Hazelcast cluster
-
DeliveryCraft malicious serialized Java gadget
-
ExploitPublish object onto cluster protocol
-
ExecutionHazelcast deserializes without class filter
-
ImpactExecute arbitrary code on Camel nodes
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the affected Camel route use the camel-hazelcast component with a Hazelcast instance built from Camel's own default configuration - i.e., no user-supplied HazelcastInstance, hazelcastConfigUri, or referenced Config bean. Any hazelcast consumer (hazelcast-topic, -queue, -seda, -map, -multimap, -replicatedmap, -list, -set) or the HazelcastAggregationRepository/HazelcastIdempotentRepository triggers the exposure by default, with no opt-in endpoint setting needed. The decisive limiting factor is network position: the attacker must be able to join or otherwise reach the Hazelcast cluster protocol, which is why CVSS rates AC:H despite PR:N/UI:N. Clusters that enforce Hazelcast authentication and TLS, or are network-segmented from untrusted hosts, sharply reduce reachability; conversely, a user-provided Hazelcast Config or HazelcastInstance is not affected at all. |
| Impact | Signals are mixed, which argues for prompt-but-not-panic patching. The CVSS base score is 8.1 (High) with AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H: network reachable, no authentication, no user interaction, but access complexity is High because the attacker must first reach or join the Hazelcast cluster - the real gate. EPSS is low (0.49%, 39th percentile) and the vulnerability is not in CISA KEV, with no public exploit identified at time of analysis, so there is no evidence of active or automated exploitation. No SSVC decision record is provided in the input. The dominant risk driver is deployment posture: clusters exposed on untrusted networks without authentication/TLS are genuinely at RCE risk (deserialization gadget chains are well understood), whereas clusters properly segmented and authenticated substantially raise the AC:H barrier. Net: a real priority for internet- or broad-LAN-exposed Camel/Hazelcast deployments, lower urgency where cluster membership is already tightly controlled. |
| Exploit ScenarioDerived | An attacker who can reach the Hazelcast cluster port (through a flat internal network, misconfigured firewall, or by joining an unauthenticated cluster) crafts a malicious serialized Java gadget-chain object and publishes it onto the cluster. When any Camel node receives the object, Hazelcast deserializes it via ObjectInputStream.readObject with no class filter, triggering arbitrary code execution on every node. No public exploit is identified at time of analysis, and the AC:H rating reflects that the attacker must first gain cluster reachability. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jul 06, 2026
Remote code execution in the Apache Camel camel-hazelcast component allows an attacker who can join or reach the Hazelcast cluster to run arbitrary code on every Camel node. The flaw exists because Camel-created Hazelcast instances apply no Java deserialization filter by default, so crafted serialized objects sent over the cluster protocol are deserialized (ObjectInputStream.readObject) before Camel processes them. It affects Camel 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x whenever a hazelcast consumer or repository uses Camel's own default configuration; there is no public exploit identified at time of analysis and EPSS is low (0.49%, 39th percentile).
Earlier versions of this analysis (2)
Remote code execution in the Apache Camel camel-hazelcast component affects releases 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x, where Camel-created Hazelcast instances run with no Java deserialization filter by default. Because objects arriving over the Hazelcast cluster protocol are deserialized via ObjectInputStream.readObject before Camel touches them, any actor able to join or reach the cluster can publish a crafted serialized object and execute code on every Camel node. This is a CWE-502 deserialization flaw carrying CVSS 8.1; there is no public exploit identified at time of analysis and EPSS is low at 0.49% (39th percentile), but the exposure exists in default configurations of a broad set of hazelcast routes and repositories.
Remote code execution in Apache Camel's Hazelcast component allows any attacker who can reach the Hazelcast cluster port to execute arbitrary code on every affected Camel node. The vulnerability stems from Camel's default-managed Hazelcast instances applying no Java deserialization filter, meaning crafted serialized objects published to any Hazelcast topic, queue, map, or related consumer are deserialized via raw ObjectInputStream.readObject before Camel applies any validation. Affected versions span the 4.0.0-4.21.0 release range across multiple LTS streams; no public exploit has been identified at time of analysis, but the default-on nature and RCE impact make this a high-priority patching target for any deployment using Hazelcast-backed Camel routes.
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.21.0, which is the primary fix; users on the 4.14.x LTS stream should move to 4.14.8, and users on the 4.18.x stream to 4.18.3. The fix makes Camel apply a default Hazelcast JavaSerializationFilterConfig (whitelisting java., javax., and org.apache.camel. prefixes and blacklisting java.net.) only to instances it creates from its own default configuration, leaving user-supplied Config or HazelcastInstance untouched. For deployments that cannot upgrade immediately, configure a deserialization filter directly on the Hazelcast instance - either a Hazelcast JavaSerializationFilterConfig or the JVM-wide system property -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* (note the JVM-wide property affects all deserialization in the process, so validate it does not break other libraries) - and enable Hazelcast cluster authentication and TLS to restrict who can reach the cluster, at the cost of added configuration and key management. Reference the vendor advisory at https://camel.apache.org/security/CVE-2026-43865.html.
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 vulnerability is a classic Java deserialization (CWE-502) issue rooted in Hazelcast's serialization layer rather than Camel's own message processing. Hazelcast, an in-memory data grid, exchanges objects between cluster members over its cluster protocol and deserializes them with ObjectInputStream. Camel's camel-hazelcast integration (CPE cpe:2.3:a:apache_software_foundation:apache_camel) builds a default Hazelcast Config when the user supplies no HazelcastInstance, hazelcastConfigUri, or referenced Config bean - and that default sets neither Hazelcast's JavaSerializationFilterConfig nor a Camel-side ObjectInputFilter. Without a class allow/deny filter, any serialized object reaching the node is instantiated, which is the standard precondition for gadget-chain-based RCE. All hazelcast consumer endpoints (topic, queue, seda, map, multimap, replicatedmap, list, set) and the HazelcastAggregationRepository and HazelcastIdempotentRepository share this exposure.
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:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Network-reachable and unauthenticated (PR:N/UI:N) but the attacker must first reach or join the cluster, so AC:H; deserialization RCE yields full C:H/I:H/A:H.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
Deserialization of Untrusted Data vulnerability in Apache Camel Hazelcast component.
The camel-hazelcast component creates and manages Hazelcast instances using a default configuration that applies no Java deserialization filter. When Camel builds the Hazelcast Config itself - that is, when no user-supplied HazelcastInstance, hazelcastConfigUri, or referenced Config bean is provided - neither Hazelcast's JavaSerializationFilterConfig nor a Camel-side ObjectInputFilter is configured, so objects received over the Hazelcast cluster protocol are deserialized inside Hazelcast's own serialization layer (ObjectInputStream.readObject) before Camel ever processes them. An attacker who can join or otherwise reach the Hazelcast cluster can publish a crafted serialized Java object that is then deserialized on every Camel node, resulting in remote code execution. The exposure is present by default and requires no opt-in endpoint configuration: any route using a hazelcast consumer (hazelcast-topic, hazelcast-queue, hazelcast-seda, hazelcast-map, hazelcast-multimap, hazelcast-replicatedmap, hazelcast-list, hazelcast-set), as well as the HazelcastAggregationRepository and HazelcastIdempotentRepository, is affected whenever the managed instance is created from Camel's default configuration. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.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.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes Camel apply a default Hazelcast JavaSerializationFilterConfig (whitelisting the java., javax. and org.apache.camel. class-name prefixes and blacklisting java.net.) to instances it creates from its own default configuration, while leaving any user-supplied Config or HazelcastInstance untouched. For deployments that cannot upgrade immediately, configure a deserialization filter on the Hazelcast instance (Hazelcast JavaSerializationFilterConfig, or the JVM-wide system property -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!*) and enable Hazelcast cluster authentication and TLS to restrict who can reach the cluster.
Articles & Coverage 1
Executive ViewAI
Apache Camel's hazelcast component contains a remote code execution vulnerability (CVE-2026-43865) affecting versions 4.0-4.20 in organizations using Camel for distributed messaging and data caching. Attackers who can reach an organization's Hazelcast cluster infrastructure can execute arbitrary code across all connected Camel nodes, enabling data theft, service disruption, and lateral network movement. The vulnerability poses material risk to enterprise messaging pipelines and cluster-based data repositories.
Apply vendor patch. If patching is delayed: restrict network access to Hazelcast cluster endpoints to only authorized Camel nodes; disable hazelcast consumer and repository components if operationally unnecessary; implement network monitoring on cluster communication channels.
Threat Intelligence Overview
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
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
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
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)
Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMat
Remote code execution in Apache Camel's camel-vertx-http component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0) arises when a p
Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern b
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constr
EUVD-2026-41826
GHSA-xww8-mxqw-m84w
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB