Unsafe Java Deserialization in Apache Camel-JGroups
CVE-2026-88900 is an unsafe Java deserialization vulnerability in Apache Camel's Camel-JGroups component affecting versions 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1. CamelJGroupsReceiver invokes JGroupsEndpoint.createExchange(Message), which obtains the exchange body through org.jgroups.Message.getObject(). For ObjectMessage messages, JGroups deserializes the payload through ObjectInputStream on its receive thread before Camel's receiver runs. Affected Camel and bundled JGroups versions apply no ObjectInputFilter on this path unless a JVM-wide serialization filter is configured. The default consumer channel uses UDP multicast without authentication or encryption. An attacker able to reach the cluster can submit a crafted serialized object and potentially execute code when a usable deserialization gadget chain exists on the application classpath. Checks performed after deserialization cannot prevent execution of deserialization callbacks.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation permits arbitrary code execution with the privileges of the Camel process, potentially compromising application-accessible data, modifying application state, and disrupting service. The vulnerability is rated high severity, with a CVSS 3.1 score of 8.8 and vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Under the default configuration, exploitation requires neither credentials nor user interaction, but does require cluster network reachability and a usable deserialization gadget chain.
If you can’t patch tonight, do this now.
Configure a restrictive JVM-wide jdk.serialFilter that allows only the classes required by legitimate cluster exchanges, ensuring filtering occurs before incoming objects are materialized. Configure JGroups AUTH together with SYM_ENCRYPT or ASYM_ENCRYPT through channelProperties, and restrict access to the cluster multicast group and bind port to trusted systems. Do not rely solely on Camel-level checks of already-deserialized objects, because deserialization callbacks execute before those checks.
Patch, then assume compromise.
Upgrade to Apache Camel 4.23.0, or to 4.22.1 or 4.18.5 on the corresponding maintenance streams. Deployments on unsupported release lines must migrate to a supported, fixed release. For 4.22.1 and 4.18.5, additionally configure a restrictive JVM-wide jdk.serialFilter or a JGroups channel secured with AUTH and either SYM_ENCRYPT or ASYM_ENCRYPT: the patched Camel-level body-class checks occur after deserialization and are only defense in depth. Version 4.23.0 includes JGroups 5.5.7.Final, supports the jgroups.deserialization.filter system property, and refuses consumer startup without a pre-deserialization protective control unless the insecure acceptAllObjects=true override is enabled. Do not enable that override.
1 exploit validated by Mallory's analysis.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
7 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.