What is the CVSS score of CVE-2026-43865?

CVE-2026-43865 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.5%.

Which versions of Apache Camel are affected by CVE-2026-43865?

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.. A patch is available.

How to fix or mitigate CVE-2026-43865?

24 hours: Identify all systems running Apache Camel 4.0.0-4.14.7, 4.15.0-4.18.2, or 4.19.0-4.20.x with hazelcast consumer or repository components; assess network exposure of Hazelcast cluster endpoints. 7 days: Review Apache Camel security advisory; test patched versions in staging environments. 30 days: Deploy patches to all affected production instances; implement network segmentation for Hazelcast cluster access; verify remediation across all systems.

Apache Camel CVE-2026-43865

EUVD-2026-41826 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-07-06 apache

GHSA-xww8-mxqw-m84w

Deserialization Java RCE Apache Apache Camel

8.1

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

8.1 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

8.1 HIGH

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.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jul 06, 2026 - 19:42 vuln.today

v3 (cvss_changed)

Analysis Updated

Jul 06, 2026 - 19:41 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 06, 2026 - 19:22 vuln.today

cvss_changed

CVSS changed

Jul 06, 2026 - 19:22 NVD

8.1 (HIGH)

Patch available

Jul 06, 2026 - 10:01 EUVD

Analysis Generated

Jul 06, 2026 - 09:29 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

9 maven packages depend on org.apache.camel:camel-hazelcast (3 direct, 6 indirect)

Ecosystem-wide dependent count for version 4.0.0.

DescriptionCVE.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

News 6 New Java Vulnerabilities - 6 High Severity, No POC Available Jul 07, 2026

AnalysisAI

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).

Technical ContextAI

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.

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.