Skip to content
THREATWIRE
HighPoC Available

CVE-2026-88900

Camel-JGroups consumer deserializes cluster messages without a filter, leading to code execution

Apache disclosed CVE-2026-88900 on 19 October 2026. The camel-jgroups consumer let JGroups Java-deserialize cluster messages with no filter. A host that can reach the cluster's default UDP multicast group can send a crafted object and run code if a gadget chain is on the classpath. Apache CVSS 3.1 8.8. Fixed in 4.18.5, 4.22.1 and 4.23.0. Public reproducer by a Camel PMC member. Not in KEV.

By ThreatWire Desk · Published 19 Oct 2026 · Updated 26 Oct 2026

CVSS
8.8
Vector
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Class
RCE
Status
PoC Available
KEV
Not in CISA KEV
0-day
No
Vendor
Apache
Products
Apache Camel, camel-jgroups
Affected
Apache Camel (org.apache.camel:camel-jgroups) from 4.0.0 before 4.18.5, and from 4.19.0 before 4.22.1. Older lines, including 4.14.x and earlier, are end of life and get no fix. The camel-jgroups-raft component is not affected.
Fixed
Apache Camel 4.18.5 (4.18.x LTS), 4.22.1 (4.22.x) and 4.23.0. On 4.18.5 and 4.22.1 a JVM-wide serialization filter or an authenticated, encrypted channel is still needed; 4.23.0 refuses to start the consumer without one.
Published
19 Oct 2026
Updated
26 Oct 2026

The status above is the claim. Links do not upgrade it.

CVE-2026-88900 is an unsafe Java deserialization flaw in camel-jgroups, the Apache Camel component for JGroups clusters. Apache published the advisory and the oss-security post on 19 October 2026.

For each message, the consumer read the body with JGroups' getObject call. For object messages, JGroups Java-deserializes the payload as it arrives. Neither Camel nor the bundled JGroups versions applied a deserialization filter.

By default the consumer uses the stock JGroups stack. It multicasts over UDP, without AUTH and without encryption. Any host that can reach the multicast group or bind port can join and send messages without credentials.

Such a host can send a crafted object. Apache says this leads to code execution in the Camel process when a usable gadget chain is on the classpath.

Two conditions limit it. The attacker needs access to the cluster network, usually an adjacent network. A gadget chain must be present. Apache cites both as the reason the rating is High, not Critical.

Apache scores it CVSS 3.1 8.8 (High). NVD shows the Apache score and has not added its own.

Affected: 4.0.0 before 4.18.5, and 4.19.0 before 4.22.1. Fixed: 4.18.5, 4.22.1 and 4.23.0. Lines 4.14.x and older, 4.15 to 4.17 and 4.19 to 4.21 are end of life.

The fix in 4.18.5 and 4.22.1 checks the class after JGroups has deserialized it. Apache says that check cannot stop code that runs during deserialization. On those releases you must also set a JVM-wide serialization filter, or secure the channel with AUTH plus encryption. Release 4.23.0 refuses to start the consumer until one such control exists.

The advisory credits h1ei1. A public reproducer repository is published by Andrea Cosentino (oscerd), the Camel PMC member who wrote the fix. ThreatWire did not run it and does not reprint its content.

The CVE is not in the CISA KEV catalog (catalog 2026.10.23). CISA's SSVC entry sets exploitation to none. No exploitation in the wild is reported.

Read the full explainer on the eight Camel and Camel K flaws. The same deserialization family includes the Redis flaw CVE-2026-78165.

Sources

Share on X@threatwire_https://www.threatwire.tech/cve/cve-2026-88900