Apache Camel JGroups CVE-2026-88900

Requires the camel-jgroups consumer running with its default channel - created via new JChannel() when neither the 'channel' nor 'channelProperties' option is configured - which uses the stock JGroups UDP multicast stack with no AUTH protocol and no encryption, allowing any host that can reach the cluster's multicast group or bind port to join and send messages without credentials. Exploitation to RCE additionally requires a usable deserialization gadget chain already present on the application classpath and the absence of a JVM-wide -Djdk.serialFilter (camel-jgroups installed no ObjectInputFilter and the shipped JGroups versions apply none). Key LIMITING factors: the default UDP multicast transport means the attacker must be on an adjacent network (AV:A), not the open internet; and without a usable gadget chain on the classpath, code execution cannot occur. Deployments that set a channel/channelProperties with AUTH and encryption, or a JVM-wide serialization filter, are not exploitable via this path.

This is a genuine high-severity concern but not an emergency. The vendor-assigned CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.8) is internally consistent with the description: the stock JChannel() created by camel-jgroups multicasts over UDP without the AUTH protocol or encryption, so any host that can reach the cluster's multicast group or bind port can send messages with no credentials (supporting PR:N), and a crafted serialized object yields full C/I/A compromise via RCE. The adjacent attack vector (AV:A) - not network (AV:N) - is the single most important risk-limiting signal and is correctly applied, since the default UDP multicast transport confines reachability to an adjacent network rather than the open internet. No EPSS score, KEV listing, or POC was provided in the input; exploitation status is therefore 'no public exploit identified at time of analysis.' A second, equally material limiting factor is that successful RCE requires a usable deserialization gadget chain to already be present on the application classpath - without one, the flaw degrades to a lower-impact deserialization issue. The vendor itself notes severity is 'high rather than critical' precisely because of the adjacent-network constraint plus the gadget-chain dependency. Bottom line: prioritize patching for any deployment that actually uses the camel-jgroups consumer with default clustering, but the combination of adjacent-only reach and classpath dependency argues against treating this as broadly wormable. No signals are in conflict; the main gap is the absence of EPSS/KEV/POC data to gauge real-world interest.

An attacker positioned on a network adjacent to the Camel deployment (e.g., the same broadcast/multicast segment) joins the unauthenticated, unencrypted default JGroups cluster and sends a crafted serialized ObjectMessage to the jgroups consumer. JGroups Java-deserializes the payload on its own receive thread before Camel's receiver runs, and if a usable gadget chain exists on the classpath, arbitrary code executes in the Camel process. No public exploit was identified at time of analysis, and the adjacent (not remote-internet) vector plus the classpath gadget-chain requirement constrain practical exploitation.