Exploit for Deserialization of Untrusted Data in Apache Camel CVE-2026-43865

## https://sploitus.com/exploit?id=75024B83-847C-578B-9116-A73213D6E9C6
# camel-hazelcast Default-Instance Unsafe Deserialization Reproducer (CVE-2026-43865)

This project demonstrates a **Java deserialization vulnerability** in Apache Camel's `camel-hazelcast`
component, tracked as **CVE-2026-43865**. When Camel builds the Hazelcast `Config` itself — i.e. when **no**
user-supplied `HazelcastInstance`, `hazelcastConfigUri`, or referenced `Config` bean is provided — it applies
**no Java deserialization filter** (neither Hazelcast's `JavaSerializationFilterConfig` nor a Camel-side
`ObjectInputFilter`). Objects arriving over the Hazelcast cluster protocol are therefore deserialized inside
Hazelcast's serialization layer (`ObjectInputStream.readObject`) with no class restrictions. An attacker who can
join or otherwise reach the cluster can publish a crafted serialized object that is deserialized on every Camel
node — **remote code execution**, present by default and requiring no opt-in endpoint configuration.

Advisory: https://camel.apache.org/security/CVE-2026-43865.html

## Vulnerability Summary

| Property | Value |
|----------|-------|
| **Component** | `camel-hazelcast` (any consumer + `HazelcastAggregationRepository` / `HazelcastIdempotentRepository`) |
| **Affected Class** | `org.apache.camel.component.hazelcast.HazelcastDefaultComponent` (default-config instance creation) |
| **CWE** | CWE-502: Deserialization of Untrusted Data |
| **Impact** | Remote Code Execution (RCE) on every Camel node in the cluster |
| **Trigger** | A hazelcast consumer/repository whose managed instance is created from Camel's **default** configuration |
| **Affected Versions** | From 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0 |
| **Fixed Versions** | 4.14.8, 4.18.3, 4.21.0 |
| **JIRA** | CAMEL-23414 |
| **Reporter** | gaorenyusi |

> This is **distinct** from the Hazelcast-library advisories CVE-2016-10750 / CVE-2022-36418 (which concern
> Hazelcast's own code). Here the flaw is Camel not applying the deserialization protection Hazelcast provides.

## Technical Details

When no instance/config is supplied, `HazelcastDefaultComponent` builds the instance from the stock config and
sets **no** serialization filter:

```java
// HazelcastDefaultComponent - affected 4.18.2
if (hazelcastInstance == null && config == null) {
    config = new XmlConfigBuilder().build();
    config.getProperties().setProperty("hazelcast.version.check.enabled", "false");
    config.getProperties().setProperty("hazelcast.phone.home.enabled", "false");
    hzInstance = Hazelcast.newHazelcastInstance(config);   // no JavaSerializationFilterConfig
}
```

The fix inserts a default filter (whitelist `java.`/`javax.`/`org.apache.camel.`, blacklist `java.net.`) on
instances Camel creates itself, leaving user-supplied `Config`/`HazelcastInstance` untouched:

```java
// fixed 4.18.3 / 4.21.0
config.getProperties().setProperty("hazelcast.phone.home.enabled", "false");
HazelcastSerializationFilterHelper.applyDefault(config);   //  In a real attack the serialized bytes are produced by the attacker's own Hazelcast client/member; only the
> **victim** needs the gadget chain on its classpath. This PoC builds the gadget in-process, which is why the
> JVM runs with `--add-opens java.base/java.util=ALL-UNNAMED` — a gadget-construction detail, unrelated to the
> vulnerability.

## Prerequisites

- Java 17+ and Maven 3.8+
- Docker (runs the reproducer)

## Reproduction Steps

### Step 1: Build and start the container

```bash
mvn clean package -DskipTests
docker compose up -d --build
```

### Step 2: Trigger the deserialization (RCE)

```bash
curl -s http://localhost:8080/exploit/attack
# -> Offered gadget to hazelcast queue 'cve' as a cluster client.
#    The Camel node's queue.poll() deserialized it via Hazelcast (no filter).
#
#    >>> RCE proof — /tmp/pwned exists: true
```

### Step 3: Verify

```bash
docker exec cve-2026-43865 ls -la /tmp/pwned
```

### Cleanup

```bash
docker compose down
```

## Attack Vectors

Any Camel route using a hazelcast consumer (`hazelcast-topic`, `hazelcast-queue`, `hazelcast-seda`,
`hazelcast-map`, `hazelcast-multimap`, `hazelcast-replicatedmap`, `hazelcast-list`, `hazelcast-set`), or the
`HazelcastAggregationRepository` / `HazelcastIdempotentRepository`, whenever the managed instance is created
from Camel's default configuration and an attacker can reach the cluster.

## Exploit Conditions

1. A camel-hazelcast consumer/repository using an instance Camel created from its **default** config (no
   user-supplied `HazelcastInstance` / `hazelcastConfigUri` / `Config` bean).
2. The attacker can join or reach the Hazelcast cluster (no authentication/TLS by default).
3. **A gadget library on the classpath** (here `commons-collections:3.2.1`).

## Recommended Fix

Upgrade to **4.14.8 / 4.18.3 / 4.21.0** (CAMEL-23414), which applies a default Hazelcast
`JavaSerializationFilterConfig` to instances Camel creates from its own default configuration.

## Mitigation

Until upgrading:

1. Configure a deserialization filter on the Hazelcast instance (`JavaSerializationFilterConfig`, or the
   JVM-wide `-Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!*`).
2. Enable Hazelcast **cluster authentication and TLS** to restrict who can reach the cluster.
3. **Remove gadget libraries** from the classpath (upgrade/remove commons-collections 3.x and similar).

## Disclaimer

This reproducer is provided for **security research and authorized testing only**, for a **publicly disclosed
and fixed** vulnerability. Do not use it against systems without explicit permission.