Apache Camel fixes four deserialisation and control-path CVEs: patch and contain
Four Apache Camel CVEs published on 19 October 2026: affected versions, safe exposure checks, vendor-supported remediation and validation.
Scope
Four Apache Camel CVEs published on 19 October 2026: affected versions, safe exposure checks, vendor-supported remediation and validation.
What changed on 19 October 2026
Apache Camel published fixes for four deserialisation and expression-injection defects that matter to teams using Camel as an integration layer. The NVD records for CVE-2026-78162, CVE-2026-78165, CVE-2026-83531 and CVE-2026-88900 were published on 19 October 2026. They do not establish active exploitation.
The affected releases are Camel 4.0.0 to before 4.18.5 and 4.19.0 to before 4.22.1 for CVE-2026-78162 and CVE-2026-88900; Camel 2.11.0 to before 4.18.5 and 4.19.0 to before 4.22.1 for CVE-2026-78165; and Camel 4.4.0 to before 4.18.5 and 4.19.0 to before 4.22.1 for CVE-2026-83531. Apache recommends 4.23.0, or 4.22.1 and 4.18.5 on maintained streams. Older end-of-life branches do not receive fixes.
CVE-2026-78162: Camel Hazelcast component
Confirmed: affected Camel configurations can create Hazelcast instances without the intended Java deserialisation filter. A party able to publish data into the attached Hazelcast cluster may reach Java deserialisation in the Camel process.
Not confirmed: the advisory does not say every deployment is internet-reachable or exploited. Reachability depends on cluster topology, network policy and authentication.
Safe exposure check: record the Camel version and search configuration for camel-hazelcast, ReplicatedHazelcastAggregationRepository, hazelcastMode=client, hazelcastConfigUri and hazelcastInstance. Confirm whether the cluster uses TLS and authentication. This is a configuration review, not an attack attempt.
Interpretation: an affected version plus a Camel-created Hazelcast client/member is evidence requiring remediation. A current version or explicitly supplied reviewed configuration reduces this specific exposure; it does not prove the cluster is secure.
CVE-2026-78165: Camel Spring Redis component
Confirmed: the default Java serializer can deserialize values read by affected Camel Spring Redis consumers and selected reads. An actor who can publish to subscribed channels or write relevant keys can influence the data being deserialised.
Not confirmed: the advisory does not assert that a public Redis endpoint is required or that a custom RedisTemplate alone protects the consumer path.
Safe exposure check: identify camel-spring-redis dependencies and endpoint URIs. Review whether a serializer option is explicitly set on each endpoint and who can reach Redis. An affected version with a missing endpoint serializer and a shared or untrusted Redis writer is a remediation priority. Do not test by publishing crafted serialised data.
CVE-2026-83531: Dynamic Router control messages
Confirmed: affected dynamic-router-control routes can compile a predicate or expression language supplied in a control message. A sender able to reach that control route may cause evaluation in the Camel process.
Not confirmed: this does not affect routes that do not use the dynamic-router-control endpoint, and it does not prove an attacker can send messages to the relevant transport.
Safe exposure check: search deployed route definitions for dynamic-router-control and for forwarding from shared transports. Record every producer identity and authentication method. An affected version plus a control route fed by an untrusted or shared transport is sufficient evidence to contain it immediately.
CVE-2026-88900: Camel JGroups component
Confirmed: Camel JGroups consumers can process Java-serialised ObjectMessage data before a route sees it. Default JGroups setup may use unauthenticated, unencrypted UDP multicast.
Not confirmed: this is not proof that every JGroups deployment is externally exposed. The relevant reachability is the multicast group or bind port, normally an adjacent-network concern.
Safe exposure check: find camel-jgroups consumers, inspect the configured channel or stack and firewall rules, and identify hosts able to join the group. An affected JGroups consumer with default or unauthenticated cluster membership needs an upgrade and network containment. A local UDP listener does not prove multicast membership or safety.
Vendor-supported remediation
- Prepare: capture deployed version, route configuration, JDK flags and rollback artefact. Confirm compatibility in staging.
- Upgrade through the normal release pipeline to 4.23.0, or the supported 4.22.1 or 4.18.5 stream. Do not jump from an unsupported line without application testing.
- Contain before the maintenance window: restrict Hazelcast, Redis and JGroups to authenticated authorised peers and trusted networks. For dynamic-router-control, stop forwarding untrusted messages to the control endpoint.
- Apply documented interim controls only when delayed: supply a reviewed Hazelcast JavaSerializationFilterConfig or pre-built configured instance; enable cluster authentication and TLS. For Spring Redis, set the endpoint serializer to a non-Java serializer such as StringRedisSerializer and restrict publishers. Test any JVM serial filter before rollout.
- Validate: confirm the version, inspect startup logs, test expected integration traffic, and verify that unauthorised test accounts cannot publish or control routes. Dynamic Router should reject message-supplied predicates unless allowPredicateFromMessage was deliberately enabled for a fully trusted sender.
- Rollback: restore the previous application artefact through the release system, retain network restrictions and interim configuration, then open a vendor-supported compatibility case. Do not remove containment as part of rollback.
NetTools.tech note
No NetTools.tech check is included: these are application dependency and private-messaging topology issues. An external port result cannot establish whether Camel deserialises data or whether a sender is authorised.