Apache Camel EUVD-2026-104224

Exploitation requires a deployment using one of two specific camel-hazelcast paths without supplying its own Hazelcast configuration or instance: (1) a route using ReplicatedHazelcastAggregationRepository without a hazelcastInstance (its doStart() never called super.doStart(), so it missed the CVE-2026-43865 default JavaSerializationFilterConfig), or (2) a client-mode endpoint (hazelcastMode=client) where neither a referenced ClientConfig nor hazelcastConfigUri is provided, causing HazelcastDefaultComponent#getOrCreateHzClientInstance() to build an unfiltered ClientConfig. The attacker must additionally be able to publish entries into the Hazelcast cluster the instance is attached to; this is eased by Hazelcast's default of no authentication and no TLS. Limiting factors: affected versions only (4.0.0-4.18.5 excl., 4.19.0-4.22.1 excl.); a user-supplied Config with a JavaSerializationFilterConfig or an injected HazelcastInstance is never overwritten and fully mitigates; a JVM-wide -Djdk.serialFilter and enabling Hazelcast auth/TLS also limit exposure.

All severity signals point the same direction and reinforce one another. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with full H across VC/VI/VA and subsequent-system SC/SI/SA) scores 10.0 and describes a network-reachable, low-complexity, unauthenticated path to remote code execution - consistent with the description, which is a CWE-502 untrusted-data deserialization leading to RCE inside Hazelcast's serialization layer before Camel even processes the exchange. The deployment default amplifies this: Hazelcast clusters ship with neither authentication nor TLS, so the 'able to publish into the cluster' precondition is often met by anyone with network reach. No EPSS score, no CISA KEV entry, and no public exploit were provided, so there is no evidence of active exploitation yet; the GitHub links are patch diffs and a regression test, not weaponized proof-of-concept code. The realistic qualifier is exposure scope rather than exploitability: only specific configurations are affected (see exploitation_conditions), so this is a genuine high-priority patch for anyone running camel-hazelcast in those modes, but it is not a blanket 'every Camel install is RCE' situation. Note the Microsoft tag in the input is erroneous - this is an Apache Software Foundation product.

An attacker with network access to an unauthenticated, non-TLS Hazelcast cluster that a vulnerable Camel instance has joined publishes a crafted serialized Java object (e.g. a gadget-chain payload) into the backing ReplicatedMap or map. When the Camel member reads that value it deserializes it with no class filter, executing attacker-controlled code on the host. No public exploit is identified at time of analysis, though CWE-502 Java gadget chains are well understood and the patch diff confirms the missing filter.