Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-43865

CVE-2026-43865: Apache Camel RCE Vulnerability

CVE-2026-43865 is a remote code execution vulnerability in Apache Camel's Hazelcast component caused by unsafe deserialization. Attackers can execute arbitrary code on Camel nodes. This article covers technical details, affected versions, and mitigation strategies.

Published:

CVE-2026-43865 Overview

CVE-2026-43865 is a deserialization of untrusted data vulnerability [CWE-502] in the 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, neither Hazelcast's JavaSerializationFilterConfig nor a Camel-side ObjectInputFilter is configured. Objects received over the Hazelcast cluster protocol are deserialized inside ObjectInputStream.readObject before Camel processes them. An attacker who can reach the Hazelcast cluster can publish a crafted serialized Java object that triggers remote code execution on every Camel node.

Critical Impact

An attacker with network access to the Hazelcast cluster can achieve unauthenticated remote code execution on all Camel nodes using the default configuration.

Affected Products

  • Apache Camel 4.0.0 through 4.14.7
  • Apache Camel 4.15.0 through 4.18.2
  • Apache Camel 4.19.0 through 4.20.x (before 4.21.0)

Discovery Timeline

  • 2026-07-06 - CVE-2026-43865 published to NVD
  • 2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-43865

Vulnerability Analysis

The vulnerability affects any Camel route using a Hazelcast consumer, including hazelcast-topic, hazelcast-queue, hazelcast-seda, hazelcast-map, hazelcast-multimap, hazelcast-replicatedmap, hazelcast-list, and hazelcast-set. The HazelcastAggregationRepository and HazelcastIdempotentRepository are also affected. The exposure is present by default and requires no opt-in endpoint configuration. Any managed instance created from Camel's default configuration inherits the missing filter.

Deserialization occurs inside Hazelcast's own serialization layer before Camel processes the message. This means gadget chains available on the classpath, such as those in commonly bundled libraries, can be triggered without touching Camel-level integration code. The result is arbitrary code execution in the JVM hosting the Camel application.

Root Cause

The root cause is the absence of a serialization filter on Hazelcast instances that Camel builds internally. When users do not provide a HazelcastInstance, a hazelcastConfigUri, or a referenced Config bean, Camel constructs a default Config without invoking JavaSerializationFilterConfig. The JVM-wide jdk.serialFilter is also not set by Camel. Hazelcast therefore accepts arbitrary Java classes during cluster message deserialization.

Attack Vector

An attacker who can join or otherwise reach the Hazelcast cluster protocol port publishes a crafted serialized Java payload to a cluster topic, queue, or map. Every Camel node in the cluster receives the object and calls ObjectInputStream.readObject, which instantiates the malicious class graph. Reachability depends on network segmentation and whether Hazelcast cluster authentication and TLS are enabled. In default deployments without cluster-level authentication, any host that can connect to the cluster port is sufficient.

Refer to the Apache Camel CVE-2026-43865 Advisory for the technical description from the project.

Detection Methods for CVE-2026-43865

Indicators of Compromise

  • Unexpected child processes spawned by the JVM running Apache Camel, such as sh, bash, cmd.exe, or powershell.exe.
  • Outbound network connections from Camel nodes to unknown hosts shortly after Hazelcast cluster messages are received.
  • Java stack traces in application logs referencing ObjectInputStream.readObject invoked from Hazelcast serialization classes with unusual class names.
  • New or unexpected members joining the Hazelcast cluster from IP addresses outside the expected topology.

Detection Strategies

  • Inventory all Apache Camel deployments and identify versions in the affected ranges (4.0.0 to 4.14.7, 4.15.0 to 4.18.2, 4.19.0 to 4.20.x).
  • Inspect Camel routes for use of hazelcast-* consumers, HazelcastAggregationRepository, or HazelcastIdempotentRepository without an explicit HazelcastInstance or hazelcastConfigUri reference.
  • Monitor JVM process telemetry for anomalous child process creation from Camel application processes.
  • Correlate Hazelcast cluster membership changes with authentication logs to identify unauthorized nodes.

Monitoring Recommendations

  • Enable verbose logging on the com.hazelcast and org.apache.camel.component.hazelcast packages to record deserialization activity.
  • Capture and alert on network flows targeting Hazelcast default ports (5701 and above) from unexpected sources.
  • Track JVM -Djdk.serialFilter settings across Camel hosts to confirm mitigation coverage.

How to Mitigate CVE-2026-43865

Immediate Actions Required

  • Upgrade to Apache Camel 4.21.0, 4.18.3, or 4.14.8 depending on the release stream in use.
  • Restrict network access to Hazelcast cluster ports using firewalls and segmentation so only trusted Camel nodes can connect.
  • Enable Hazelcast cluster authentication and TLS to prevent unauthorized cluster membership.
  • Audit application classpaths for known deserialization gadget libraries and remove those not required.

Patch Information

Apache Camel 4.21.0 fixes CVE-2026-43865. The 4.14.x LTS stream is fixed in 4.14.8, and the 4.18.x stream is fixed in 4.18.3. The patch makes Camel apply a default Hazelcast JavaSerializationFilterConfig to instances it creates from its own default configuration. The filter whitelists the java., javax., and org.apache.camel. class-name prefixes and blacklists java.net.. User-supplied Config or HazelcastInstance objects remain untouched. See the Apache Camel CVE-2026-43865 Advisory and the Openwall OSS-Security Mailing List Post for details.

Workarounds

  • Configure a Hazelcast JavaSerializationFilterConfig on the Hazelcast instance to whitelist required classes and blacklist java.net.**.
  • Set the JVM-wide system property -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* on all Camel nodes if upgrading is not immediately feasible.
  • Provide an explicit HazelcastInstance or hazelcastConfigUri bean with a configured serialization filter instead of relying on Camel's default configuration.
  • Enforce Hazelcast cluster-level authentication and TLS mutual authentication to restrict who can publish messages to the cluster.
bash
# Configuration example: enable JVM-wide deserialization filter for Camel nodes
java -Djdk.serialFilter='!java.net.**;java.**;javax.**;org.apache.camel.**;!*' \
     -jar camel-application.jar

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.