Apache Camel Vulnerability Allows Remote Code Execution via Deserialization
A critical flaw in Apache Camel enables remote code execution by allowing unrestricted deserialization of data within Hazelcast components.
Key points
- Remote code execution is possible via the camel-hazelcast component in affected Apache Camel versions.
- The flaw stems from missing serialization filters on specific configuration paths within the software.
- Users should upgrade to version 4.23.0 or apply explicit configuration workarounds if upgrades are not possible.
An attacker able to publish data into a Hazelcast cluster attached to an affected Apache Camel instance can cause a serialized Java object to be deserialized, resulting in remote code execution. The threat actor does not need to interact with Camel directly, as the malicious object is processed by Hazelcast’s serialization layer before Camel handles the exchange. This capability exists because the deserialization process lacks class restrictions. According to the National Vulnerability Database, the issue is rated as critical severity.
In plain English
The problem lies in how Apache Camel handles data coming from Hazelcast, a distributed caching system. When Camel creates Hazelcast instances using certain internal configuration paths, it fails to apply a safety filter that limits which types of data can be processed. This allows an attacker to send specially crafted data that the system blindly accepts and runs. The weakness affects both server-side members and client-mode connections, meaning the risk exists regardless of how the application is deployed.
The background
This vulnerability, tracked as CVE-2026-78162, affects Apache Camel versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. It emerged because a previous fix for a related deserialization issue did not cover all ways Camel builds Hazelcast instances. Specifically, the ReplicatedHazelcastAggregationRepository and client-mode configurations bypassed the protective measures introduced earlier. Consequently, these paths continued to allow unrestricted Java deserialization, leaving them open to exploitation.
What changes now
The Apache Software Foundation has released version 4.23.0, which resolves this issue. Users on older supported streams should upgrade to 4.22.1 or 4.18.5, depending on their current release line. Versions prior to 4.14.x have reached end of life and will not receive a patch, requiring affected deployments to move to a supported version. For those unable to upgrade immediately, applying explicit Hazelcast configurations with serialization filters serves as a temporary mitigation.
What made it possible
Deserialization vulnerabilities occur when an application processes incoming data without verifying its structure or content. In this scenario, the weakness allowed untrusted data to be converted back into executable objects, bypassing security controls. This technique typically serves as an initial access vector, granting attackers remote code execution before they can move laterally. Teams usually monitor for unexpected deserialization attempts and ensure that strict filtering is applied to all external data inputs to prevent such abuse.
Background: Java deserialization vulnerabilities
Java deserialization converts byte streams into object instances. If an application deserializes untrusted data without validation, attackers inject crafted objects that trigger dangerous code during reconstruction. This bypasses traditional input filters because the payload is structural, not textual.
Read the full guide: Java Deserialization Vulnerabilities: How Object Streams Break Security
What to do and how to stay safe: Apache Camel
- Upgrade Apache Camel to version 4.23.0 or the latest patch in your supported release stream to eliminate the vulnerability.
- If upgrading is not possible, configure explicit Hazelcast settings with JavaSerializationFilterConfig to restrict deserialized classes.
- Enable authentication and TLS on Hazelcast clusters to limit who can publish data and intercept potential attacks.
- Monitor server logs for unusual process executions or network connections that may indicate exploitation attempts.
Step-by-step guide: Automatic Updates Mistakes That Leave Systems Exposed
General security guidance from the RedTeam Monitor newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of Apache Camel are affected by this vulnerability?
Versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1 are affected.
Is there a fix available for older end-of-life versions?
No, versions 4.14.x and earlier have reached end of life and will not receive a fix.
How can users mitigate the risk if they cannot upgrade immediately?
Users can supply an explicit Hazelcast configuration with a serialization filter or set a JVM-wide filter.
