CVE-2026-88900
Description
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.
Statement
Red Hat Product Security rates this vulnerability as Important because an unauthenticated attacker with adjacent network access can execute arbitrary code within the application runtime. While standard camel-jgroups consumer channels lack transport authentication by default, exploitation requires network reachability to the cluster multicast address or UDP bind port and the presence of exploitable gadget classes on the Java classpath. Workloads that do not utilize camel-jgroups consumer endpoints are not exposed to this issue.
Mitigation
--- CME Mitigation Guidance (2026-10-20) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to enforce JVM-wide JEP-290 serialization filters on the Java runtime and require authentication and encryption on JGroups cluster communication channels: upgrade to Apache Camel 4.18.5, 4.22.1, or 4.23.0 (or the fixed Camel Jgroups builds), which filter the deserialized message body type against an ObjectInputFilter allow-list before routing the exchange, closing all 2 injection vectors (crafted serialized object in JGroups ObjectMessage, unauthenticated JGroups cluster membership join). Until patched, this is a concern on deployments running Camel Jgroups consumer channels exposed on an adjacent network, so configure a JVM-wide serialization filter via jdk.serialFilter, enable the AUTH protocol and encryption on JGroups channel configurations, and restrict network access to cluster multicast groups and UDP bind ports. As a compensating measure, deploy EDR agents to detect anomalous process spawning or post-exploitation payloads executed by the Java runtime following gadget chain execution and use Falco or eBPF runtime security to detect suspicious runtime behaviors such as interactive shell execution or abnormal network connections originating from the Camel Java process. These controls limit blast radius and contain exploitation, but they do not fix the underlying unsafe Java deserialization defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-1302 Deserialization Allowlist (Safe Loading) (high)
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 8.8 | N/A | 8.8 |
| Attack Vector | Adjacent Network | N/A | Adjacent Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | High | N/A | High |
Vector
Red Hat: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
cve.org: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Understanding the Weakness (CWE)
Integrity
Technical Impact: Modify Application Data; Unexpected State
Attackers can modify unexpected objects or data that was assumed to be safe from modification. Deserialized data or code could be modified without using the provided accessor functions, or unexpected functions could be invoked.
Availability
Technical Impact: DoS: Resource Consumption (CPU)
If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other
Technical Impact: Varies by Context
The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation. One example is attackers using gadget chains to perform unauthorized actions, such as generating a shell.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
