CVE-2026-78162
Apache Camel : Filtre de désérialisation Java manquant pour les instances gérées de Camel-Hazelcast (correctif incomplet pour CVE-2026-43865)
- Publié
- 19 oct. 2026
- Mise à jour
- 20 oct. 2026
- Attribution de CNA
- apache
- Preuve observée
- 17 oct. 2026
CVSS primaire
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:HRésumé
Vulnérabilité de désérialisation de données non fiables dans Apache Camel. Ce problème affecte Apache Camel : de 4.0.0 avant 4.18.5, de 4.19.0 avant 4.22.1. Le composant camel-hazelcast applique un Hazelcast JavaSerializationFilterConfig par défaut aux instances qu'il crée à partir de sa propre configuration, une protection introduite par CVE-2026-43865. Cette modification n'a pas atteint deux des chemins de configuration que Camel construit lui-même, de sorte que ces chemins ont continué à créer des instances Hazelcast dont la désérialisation Java est non restreinte. ReplicatedHazelcastAggregationRepository étend HazelcastAggregationRepository mais redéfinit doStart() sans appeler super.doStart(), en conservant sa propre copie du bloc d'amorçage, et n'a donc jamais reçu le filtre : une route l'utilisant sans fournir de hazelcastInstance démarre un membre Hazelcast qui désérialise les valeurs lues depuis le ReplicatedMap sous-jacent sans aucune restriction de classe. HazelcastDefaultComponent#getOrCreateHzClientInstance() construit son propre ClientConfig lorsque hazelcastMode=client est sélectionné et qu'aucun ClientConfig référencé ni hazelcastConfigUri n'est fourni, et n'appliquait de même aucun filtre, de sorte que les points de terminaison en mode client se comportaient différemment des points de terminaison en mode nœud pour une configuration par ailleurs identique. Dans les deux cas, un attaquant capable de publier dans le cluster Hazelcast auquel l'instance affectée est rattachée peut provoquer la désérialisation d'un objet Java sérialisé de son choix au sein de la propre couche de sérialisation de Hazelcast, avant que Camel ne traite l'échange, entraînant une exécution de code à distance. Les clusters Hazelcast n'ont par défaut ni authentification ni TLS activés. La sélection du mode client relève d'un choix de topologie et non d'une option de sécurité, de sorte qu'aucun des deux chemins n'exigeait que le déploiement opte pour un comportement non sûr. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.23.0, qui corrige le problème. Si les utilisateurs se trouvent sur la branche de versions 4.22.x, il leur est suggéré de mettre à niveau vers 4.22.1. Si les utilisateurs se trouvent sur la branche de versions 4.18.x, il leur est suggéré de mettre à niveau vers 4.18.5. La branche de versions 4.14.x et les versions antérieures ont atteint leur fin de vie avant la résolution de ce problème et ne recevront pas de correctif, de sorte que les déploiements sur ces branches doivent migrer vers une version prise en charge. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, fournissez une configuration Hazelcast explicite comportant un JavaSerializationFilterConfig, ou injectez une HazelcastInstance préconstruite, car une configuration fournie par l'utilisateur n'est jamais écrasée par Camel. Vous pouvez également définir le filtre à l'échelle de la JVM -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* et activer l'authentification et TLS du cluster Hazelcast afin de restreindre qui peut atteindre le cluster.
Utilisation responsable
Utilisez les informations de vulnérabilité uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à tester. Kitploit renvoie aux métadonnées de la recherche publique et ne stocke pas de code d'exploitation ni de charges utiles malveillantes.