Apache Camel camel-hazelcast deserialization flaw allows RCE (CVE-2026-78162)

Critical 9.8CVE-2026-78162

Apache Camel camel-hazelcast deserialization flaw allows RCE (CVE-2026-78162)

Apache Camel has a critical deserialization of untrusted data vulnerability, tracked as CVE-2026-78162, in its camel-hazelcast component. It can lead to remote code execution. The flaw exists because a protection added for an earlier issue, CVE-2026-43865, never reached two configuration paths that Camel builds itself. Hazelcast instances created through those paths still perform Java deserialization with no class restrictions.

NVD rates the issue 9.8 out of 10 (critical). As of the record date it is not listed in CISA’s Known Exploited Vulnerabilities catalog. Fixed releases are available, but the 4.14.x line and earlier will not receive a fix.

What’s affected

According to the advisory data, these Apache Camel versions are affected:

  • 4.0.0 up to, but not including, 4.18.5
  • 4.19.0 up to, but not including, 4.22.1

The vulnerable paths in camel-hazelcast are:

  • ReplicatedHazelcastAggregationRepository, when a route uses it without supplying a hazelcastInstance. This class never received the default JavaSerializationFilterConfig. The Hazelcast member it starts deserializes values from the backing ReplicatedMap with no class restriction.
  • Client-mode endpoints (hazelcastMode=client), when neither a referenced ClientConfig nor hazelcastConfigUri is supplied. In this case Camel builds its own client configuration with no filter.

The advisory notes that choosing client mode is a topology decision, not a security setting. Neither path required administrators to opt in to unsafe behaviour.

How serious is it

The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In plain terms:

  • The flaw can be reached over the network.
  • It is not complex to trigger.
  • It needs no privileges and no user interaction.
  • Successful exploitation fully compromises confidentiality, integrity and availability.

The precondition is that an attacker can publish data into the Hazelcast cluster the affected instance is attached to. The malicious object is deserialized inside Hazelcast’s own serialization layer, before Camel processes the exchange. This matters because Hazelcast clusters have neither authentication nor TLS enabled by default. Any host that can reach the cluster may therefore be able to supply data to it.

Is it being exploited?

CVE-2026-78162 is not in CISA’s Known Exploited Vulnerabilities catalog as of the record date (2026-11-14). The supplied records contain no reports of exploitation in the wild.

What to do

  • Upgrade. Apache recommends version 4.23.0.
    • On the 4.22.x stream, upgrade to 4.22.1.
    • On the 4.18.x stream, upgrade to 4.18.5.
  • Move off end-of-life lines. The 4.14.x stream and earlier reached end of life before the fix and will not be patched. Deployments on those lines must migrate to a supported release.
  • If you can’t upgrade yet, use one of these vendor-documented mitigations:
    • Supply an explicit Hazelcast configuration that includes a JavaSerializationFilterConfig.
    • Inject a pre-built HazelcastInstance. Camel never overwrites a user-supplied configuration.
  • Alternatively, set a JVM-wide serialization filter: -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!*
  • Restrict cluster access. Enable Hazelcast cluster authentication and TLS, and limit network access to the cluster to trusted hosts.
  • Audit your routes. Look for use of ReplicatedHazelcastAggregationRepository and for hazelcastMode=client endpoints without an explicit configuration.

References