CVE-2026-78165

Résumé

Vulnérabilité de désérialisation de données non fiables dans le composant Apache Camel Spring Redis. Ce problème affecte Apache Camel : de 2.11.0 avant 4.18.5, de 4.19.0 avant 4.22.1. RedisConfiguration.getSerializer construisait paresseusement un JdkSerializationRedisSerializer nu chaque fois qu'aucune option de sérialiseur n'était configurée, et cette instance était utilisée pour chaque lecture effectuée par le composant. L'implémentation de Spring délègue via DeserializingConverter à DefaultDeserializer, qui lit les octets avec un ConfigurableObjectInputStream et n'installe aucun java.io.ObjectInputFilter sur le flux, de sorte qu'un graphe de classes sérialisées arbitraire était matérialisé et que sa méthode readObject était exécutée. RedisConsumer.setBody appliquait ce sérialiseur aux octets bruts de chaque message publié sur les canaux souscrits, avant la construction de l'Exchange et donc avant que toute logique de route puisse inspecter le message, de sorte qu'un acteur capable d'émettre PUBLISH sur un canal souscrit atteignait directement le point de désérialisation. Le même sérialiseur par défaut alimentait le RedisTemplate construit par RedisConfiguration.createDefaultTemplate, de sorte que les commandes de lecture du producteur GET, HGET, HGETALL et HVALS désérialisaient tout ce qui était stocké dans l'espace de clés Redis, et SpringRedisIdempotentRepository partageait ce template. La configuration d'un redisTemplate personnalisé ne fermait pas le chemin du consommateur, car RedisConsumer.setBody lit getSerializer directement plutôt que le sérialiseur attaché au template, de sorte qu'un déploiement ayant câblé un sérialiseur String dans son propre template restait exposé côté consommateur à moins qu'il ne définisse également l'option serializer. Le composant ne construisait jamais lui-même un java.io.ObjectInputStream, ce qui explique pourquoi les passes antérieures sur la base de code Camel à la recherche de désérialisation Java non filtrée ne l'avaient pas atteint. Le comportement remonte à l'introduction du composant, publié pour la première fois dans 2.11.0, et est resté inchangé jusqu'à ce correctif. 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 a atteint sa fin de vie avant que ce problème ne soit résolu et ne recevra 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, définissez la propriété système jdk.serialFilter à l'échelle de la JVM, que le chemin de code affecté respecte car il lit via un java.io.ObjectInputStream, par exemple -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; ou définissez l'option de point de terminaison serializer sur un sérialiseur qui n'utilise pas la sérialisation Java, tel que StringRedisSerializer, en notant que cela doit être défini comme option serializer et pas seulement sur un redisTemplate personnalisé. En défense en profondeur, exigez l'authentification sur l'instance Redis et restreignez les clients autorisés à publier sur les canaux souscrits, et n'exposez pas une instance Redis consommée par Camel à des réseaux non fiables.