Apache Camel Fixes Critical Deserialization Flaw CVE-2026-78162
A critical remote code execution vulnerability in Apache Camel allows unrestricted Java deserialization in Hazelcast components, requiring immediate upgrades.
Key points
- CVE-2026-78162 is rated CVSS 10.0 Critical and affects Apache Camel versions prior to 4.18.5 and 4.22.1.
- The flaw stems from missing serialization filters in specific Hazelcast configuration paths, enabling remote code execution.
- Vendors recommend upgrading to 4.23.0, 4.22.1, or 4.18.5, or applying explicit serialization filters as a mitigation.
Apache Camel has released fixes for CVE-2026-78162, a critical deserialization vulnerability in its Hazelcast component that allows remote code execution. The flaw affects versions 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, according to the National Vulnerability Database record.
At a glance
- CVE
- CVE-2026-78162
- Product
- Apache Camel
- CVSS
- 10 Critical
- Weakness
- insecure deserialization
- Exploited
- No known exploitation
The vulnerability arises because previous security improvements did not cover all configuration paths within the camel-hazelcast component. Specifically, the ReplicatedHazelcastAggregationRepository and client-mode instances failed to apply default Java serialization filters, leaving them open to untrusted data deserialization.
Technical Context and Background
The issue was introduced when a prior fix for CVE-2026-43865 added default Hazelcast JavaSerializationFilterConfig protections. However, this protection did not reach two specific configuration paths that Camel builds internally. Consequently, these paths continued to create Hazelcast instances with unrestricted Java deserialization capabilities.
The ReplicatedHazelcastAggregationRepository class overrides the doStart method without calling the parent method. This bypasses the standard bootstrap block that applies the security filter. As a result, routes using this repository without a supplied hazelcastInstance start a member that deserializes values from the ReplicatedMap without class restrictions.
Similarly, the HazelcastDefaultComponent method getOrCreateHzClientInstance builds its own ClientConfig when hazelcastMode is set to client. If no referenced ClientConfig or hazelcastConfigUri is supplied, this method applies no filter. This causes client-mode endpoints to behave differently from node-mode endpoints for identical configurations, creating a security gap.
An attacker who can publish data into the affected Hazelcast cluster can cause a serialized Java object of their choosing to be deserialized. This occurs within Hazelcast's serialization layer before Camel processes the exchange, leading to remote code execution. Hazelcast clusters do not enable authentication or TLS by default, increasing the risk.
Who Is Affected
Apache Camel versions 4.0.0 up to but not including 4.18.5 are affected by this vulnerability. Additionally, versions 4.19.0 up to but not including 4.22.1 contain the flaw, according to the NVD record.
Deployments running the 4.14.x release stream or earlier reached end of life before this issue was resolved. These older lines will not receive a fix for CVE-2026-78162. Users on these unsupported versions must migrate to a supported release to address the vulnerability.
What should you do?
Users are recommended to upgrade to Apache Camel version 4.23.0, which fixes the issue. For those on the 4.22.x release stream, upgrading to version 4.22.1 is suggested. Users on the 4.18.x stream should upgrade to version 4.18.5.
For deployments that cannot upgrade immediately, administrators should supply an explicit Hazelcast configuration carrying a JavaSerializationFilterConfig. Alternatively, injecting a pre-built HazelcastInstance prevents Camel from overwriting the configuration. Another mitigation is setting the JVM-wide filter -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* and enabling Hazelcast cluster authentication and TLS.
What to do and how to stay safe: Apache Camel
- Verify if your Apache Camel version falls within the affected ranges (before 4.18.5 or before 4.22.1) and plan an immediate upgrade to a patched version.
- If upgrading is not possible, configure explicit JavaSerializationFilterConfig in your Hazelcast setup to restrict deserialized classes and prevent arbitrary code execution.
- Enable authentication and TLS on all Hazelcast clusters to ensure that only authorized entities can publish data to the cluster and trigger deserialization.
- Monitor network traffic for unusual Java object transmissions or unexpected process executions on systems running vulnerable Camel instances.
Step-by-step guide: Risk-Based Vulnerability Management: Prioritize Fixes by Actual Danger
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which Apache Camel versions are vulnerable to CVE-2026-78162?
Versions 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1 are affected by this critical deserialization flaw.
Can I mitigate the issue without upgrading Apache Camel?
Yes, you can supply an explicit Hazelcast configuration with a JavaSerializationFilterConfig or set a JVM-wide serial filter to restrict deserialization.
Will older Apache Camel versions receive a fix for this vulnerability?
No, the 4.14.x release stream and earlier reached end of life and will not receive a fix for this issue.
