CVE-2026-88900
published 2026-10-19CVE-2026-88900: Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0…
PriorityP357high8.8CVSS 3.1
AVAACLPRNUINSUCHIHAH
EPSS
0.32%
24.1th percentile
Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster's multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel's receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster's multicast group or bind port, which with
Affected
2 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache_software_foundation | apache_camel | >= 4.0.0 < 4.18.5 | 4.18.5 |
| apache_software_foundation | apache_camel | >= 4.19.0 < 4.22.1 | 4.22.1 |
CVSS provenance
nvdv3.18.8HIGHCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vendor_redhat8.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
org.apache.camel/camel-jgroups: camel-jgroups: Arbitrary code execution via untrusted data deserialization
vendor_redhat·2026-10-19·CVSS 8.8
CVE-2026-88900 [HIGH] CWE-502 org.apache.camel/camel-jgroups: camel-jgroups: Arbitrary code execution via untrusted data deserialization
org.apache.camel/camel-jgroups: camel-jgroups: Arbitrary code execution via untrusted data deserialization
A flaw was found in Apache Camel's camel-jgroups component. This vulnerability allows an unauthenticated attacker on an adjacent network to achieve arbitrary code execution on the target system. By default, the component joins cluster communication channels without authentication or encryption and deserializes incoming messages without validation, allowing a crafted serialized object to execute code when processed.
Package: camel-jgroups (Red Hat Fuse 7) - Out of support scope
GHSA
Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.
ghsa_unreviewed·2026-10-19
CVE-2026-88900 [HIGH] CWE-502 Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.
Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups
No detection rules found.
No public exploits indexed.
https://camel.apache.org/security/CVE-2026-40860.htmlhttps://camel.apache.org/security/CVE-2026-88900.htmlhttps://github.com/apache/camel/pull/26267https://github.com/apache/camel/pull/26281https://github.com/apache/camel/pull/26282https://github.com/apache/camel/pull/26283https://github.com/apache/camel/pull/26326https://github.com/apache/camel/pull/27205https://issues.apache.org/jira/browse/CAMEL-24676https://issues.apache.org/jira/browse/CAMEL-25223
2026-10-19
Published