Deserialization of untrusted data in Apache Camel’s camel-hazelcast component allows a malicious actor who can reach the Hazelcast cluster to send a crafted serialized Java object. Because the default configuration lacks a Java deserialization filter, the object is deserialized by Camel’s internal Hazelcast layer before any application‑level processing, leading to arbitrary code execution with the privileges of the running Camel process. This is a CWE-502 vulnerability and results in a high‑severity security flaw.

Apache Camel versions 4.0.0 through just before 4.14.8, 4.15.0 through just before 4.18.3, and 4.19.0 through just before 4.21.0 are affected. The flaw resides in the camel-hazelcast component and impacts any route that uses 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 whenever the Camel-managed instance is created from its default configuration.

The CVSS score of 8.1 indicates a high severity weakness, while the EPSS probability is below 1%. The vulnerability is not listed in CISA’s KEV catalog. An attacker who can join or otherwise reach the Hazelcast cluster can publish a malicious payload that is deserialized without filtering on every Camel node, enabling remote code execution. The exposure is present by default and requires no opt-in endpoint configuration, thereby increasing the attack surface for deployments that do not limit cluster membership or enforce authentication and TLS.