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

