CVE-2026-78162
Apache Camel: Fehlender Java-Deserialisierungsfilter bei Camel-Hazelcast Managed Instances (unvollständiger Fix für CVE-2026-43865)
- Veröffentlicht
- 19.10.2026
- Aktualisiert
- 19.10.2026
- CNA zuweisen
- apache
- Beweise beobachtet
- 17.10.2026
Primäres CVSS
cvelist · CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:HZusammenfassung
Deserialisierung nicht vertrauenswürdiger Daten – Schwachstelle in Apache Camel. Dieses Problem betrifft Apache Camel: von 4.0.0 vor 4.18.5, von 4.19.0 vor 4.22.1. Die Komponente camel-hazelcast wendet eine standardmäßige Hazelcast JavaSerializationFilterConfig auf die Instanzen an, die sie aus ihrer eigenen Konfiguration erstellt – ein Schutz, der mit CVE-2026-43865 eingeführt wurde. Diese Änderung erreichte zwei der Konfigurationspfade nicht, die Camel selbst aufbaut, sodass diese Pfade weiterhin Hazelcast-Instanzen erzeugten, deren Java-Deserialisierung uneingeschränkt ist. ReplicatedHazelcastAggregationRepository erweitert HazelcastAggregationRepository, überschreibt jedoch doStart(), ohne super.doStart() aufzurufen, behält seine eigene Kopie des Bootstrap-Blocks bei und erhielt daher nie den Filter: Eine Route, die es verwendet, ohne eine hazelcastInstance bereitzustellen, startet ein Hazelcast-Mitglied, das Werte, die aus der zugrunde liegenden ReplicatedMap gelesen werden, ohne Klassenbeschränkung deserialisiert. HazelcastDefaultComponent#getOrCreateHzClientInstance() baut seine eigene ClientConfig auf, wenn hazelcastMode=client gewählt wird und weder eine referenzierte ClientConfig noch eine hazelcastConfigUri bereitgestellt wird, und wandte ebenfalls keinen Filter an, sodass sich Endpunkte im Client-Modus bei ansonsten identischer Konfiguration anders verhielten als Endpunkte im Node-Modus. In beiden Fällen kann ein Angreifer, der in den Hazelcast-Cluster veröffentlichen kann, mit dem die betroffene Instanz verbunden ist, bewirken, dass ein serialisiertes Java-Objekt seiner Wahl innerhalb der Serialisierungsschicht von Hazelcast deserialisiert wird, bevor Camel den Exchange verarbeitet, was zur Ausführung von beliebigem Code führt. Hazelcast-Cluster haben standardmäßig weder Authentifizierung noch TLS aktiviert. Die Wahl des Client-Modus ist eine Topologieentscheidung und keine Sicherheitsoption, sodass keiner der beiden Pfade erforderte, dass sich die Bereitstellung für unsicheres Verhalten entscheidet. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer den Release-Zweig 4.22.x verwenden, wird ihnen empfohlen, auf 4.22.1 zu aktualisieren. Wenn Benutzer den Release-Zweig 4.18.x verwenden, wird ihnen empfohlen, auf 4.18.5 zu aktualisieren. Der Release-Zweig 4.14.x und frühere erreichten das Ende ihrer Lebensdauer, bevor dieses Problem behoben wurde, und erhalten keinen Fix, sodass Bereitstellungen auf diesen Linien auf eine unterstützte Version wechseln müssen. Für Bereitstellungen, die nicht sofort aktualisieren können, stellen Sie eine explizite Hazelcast-Konfiguration bereit, die eine JavaSerializationFilterConfig enthält, oder injizieren Sie eine vorgefertigte HazelcastInstance, da eine vom Benutzer bereitgestellte Konfiguration niemals von Camel überschrieben wird. Alternativ setzen Sie den JVM-weiten Filter -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* und aktivieren Sie die Hazelcast-Cluster-Authentifizierung und TLS, um einzuschränken, wer den Cluster erreichen kann.
Verantwortungsvoller Umgang
Verwenden Sie Schwachstelleninformationen nur auf Systemen, die Sie besitzen oder zu deren Testen Sie berechtigt sind. Kitploit verlinkt auf öffentliche Forschungsmetadaten und speichert keinen Exploit-Code oder bösartige Payloads.