Executive brief
Apache Camel's Hazelcast component, used for distributed messaging and caching in microservices environments, applies no deserialization filters by default. An attacker who can reach the Hazelcast cluster can inject a malicious serialized Java object that executes arbitrary code on every Camel node in the cluster. This vulnerability affects all default configurations and requires no special endpoint setup—any application using Hazelcast consumers or repositories is at risk.
Technical details
The camel-hazelcast component creates managed Hazelcast instances with a default configuration that does not configure Hazelcast's JavaSerializationFilterConfig or a Camel-side ObjectInputFilter. Objects received over the Hazelcast cluster protocol are deserialized via ObjectInputStream.readObject inside Hazelcast's serialization layer before Camel processes them. An attacker who can join the cluster or otherwise reach it can publish a crafted serialized Java object that is then deserialized on every Camel node, resulting in remote code execution. The vulnerability affects any route using hazelcast consumers (hazelcast-topic, hazelcast-queue, hazelcast-seda, hazelcast-map, hazelcast-multimap, hazelcast-replicatedmap, hazelcast-list, hazelcast-set), as well as HazelcastAggregationRepository and HazelcastIdempotentRepository, whenever the managed instance is created from Camel's default configuration. Attack preconditions include network access to the Hazelcast cluster; no authentication or user interaction is required. Patches are available in versions 4.14.8 (LTS), 4.18.3, and 4.21.0, which apply a default Hazelcast JavaSerializationFilterConfig whitelisting safe class prefixes and blacklisting java.net.*.
Affected products
- Apache Camel 4.0.0 to 4.14.7, 4.15.0 to 4.18.2, 4.19.0 to 4.20.x
Timeline
- 2026-07-06: disclosed: Published to GitHub Advisory Database
- 2026-07-06: patched: Patches released: 4.14.8, 4.18.3, 4.21.0