CVE-2026-88900

Résumé

Vulnérabilité de désérialisation de données non fiables dans le composant Camel-Jgroups d'Apache Camel. Ce problème affecte Apache Camel : de 4.0.0 avant 4.18.5, de 4.19.0 avant 4.22.1. JGroupsEndpoint.createExchange(Message), que CamelJGroupsReceiver appelle pour chaque message reçu par le consommateur jgroups avant que l'échange ne soit routé, définissait le corps de l'échange à partir de org.jgroups.Message.getObject(). Pour un ObjectMessage, qui est le type de message envoyé par le producteur Camel jgroups, JGroups désérialise en Java la charge utile via un ObjectInputStream sur son propre thread de réception à l'arrivée du message, et getObject() renvoie l'objet résultant. Aucun java.io.ObjectInputFilter n'était appliqué sur ce chemin, sauf si le déploiement avait défini un filtre de sérialisation à l'échelle de la JVM : camel-jgroups n'en installait aucun, et les versions de JGroups livrées avec les versions affectées n'en appliquent aucun de leur côté, de sorte que toute classe sérialisable présente sur le classpath de l'application pouvait être instanciée et ses callbacks de désérialisation exécutés. Sauf si un canal ou l'option channelProperties est configuré, le consommateur crée son canal avec new JChannel(), la pile de protocoles JGroups standard, qui diffuse en multicast sur UDP sans le protocole AUTH et sans chiffrement, de sorte que tout hôte capable d'atteindre le groupe multicast ou le port de liaison du cluster peut rejoindre le cluster et envoyer des messages au consommateur sans identifiants. Un tel hôte pourrait envoyer un objet sérialisé forgé conduisant à une exécution de code à distance dans le processus Camel lorsqu'une chaîne de gadgets de désérialisation exploitable est présente sur le classpath, et aucune option non par défaut n'était requise côté consommateur. Comme JGroups matérialise l'objet avant l'exécution du récepteur de Camel, une vérification effectuée par Camel ne peut qu'inspecter le résultat désérialisé et ne peut pas arrêter le code qui s'exécute pendant la désérialisation ; la clôture du problème exige donc également un contrôle qui s'applique avant la lecture de la charge utile, comme décrit dans la mesure d'atténuation. L'exploitation nécessite un accès réseau au groupe multicast ou au port de liaison du cluster, ce qui, avec le transport multicast UDP par défaut, implique un hôte sur un réseau adjacent, ainsi qu'une chaîne de gadgets exploitable sur le classpath, ce qui explique pourquoi la gravité est évaluée comme élevée plutôt que critique. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.23.0, qui corrige le problème. Si les utilisateurs sont sur la branche des versions 4.22.x, il leur est suggéré de mettre à niveau vers 4.22.1. Si les utilisateurs sont sur la branche des versions 4.18.x, il leur est suggéré de mettre à niveau vers 4.18.5. La branche des versions 4.14.x et antérieures, ainsi que les lignes de versions 4.15.x à 4.17.x et 4.19.x à 4.21.x, ont atteint leur fin de vie avant la résolution de ce problème et ne recevront pas de correctif ; les déploiements sur ces lignes doivent donc migrer vers une version prise en charge.