CVE-2026-43866

Résumé

Vulnérabilité de désérialisation de données non fiables dans Apache Camel, composant Apache Camel JMS. JmsBinding.extractBodyFromJms() dans camel-jms — et l'équivalent JmsBinding dans camel-sjms — désérialise la charge utile d'un ObjectMessage JMS entrant via jakarta.jms.ObjectMessage.getObject() chaque fois que l'option mapJmsMessage est activée (par défaut) et que Camel agit en tant que consommateur JMS. Le durcissement CVE-2026-40860 a ajouté une vérification de classe post-désérialisation qui rejette les classes en dehors de la liste d'autorisation par défaut java.**;javax.**;org.apache.camel.**;!*. Cependant, org.apache.camel.support.DefaultExchangeHolder lui-même se trouve dans l'espace de noms autorisé org.apache.camel.**, de sorte qu'un ObjectMessage dont l'objet de premier niveau est un DefaultExchangeHolder passe la vérification. Le côté récepteur appelle ensuite DefaultExchangeHolder.unmarshal() dessus sans exiger que l'option transferExchange soit activée — une frontière de confiance asymétrique, puisque le côté émetteur conditionne le traitement d'ObjectMessage et de transferExchange mais que le côté récepteur ne le fait pas — écrivant chaque champ non nul du holder dans l'Exchange : le corps du message, les en-têtes IN et OUT, les propriétés de l'échange, les variables, l'identifiant de l'échange et l'exception. Un attaquant capable de publier un ObjectMessage sur une file d'attente ou un sujet consommé par une application Camel affectée peut donc injecter un état Exchange arbitraire en utilisant uniquement des types java.lang et java.util universellement fiables, sans nécessiter de chaîne de gadgets de désérialisation, pour manipuler le routage et les en-têtes, les propriétés de l'échange et la gestion des erreurs. Le même traitement s'applique à camel-sjms et camel-sjms2, ainsi qu'aux composants de la famille JMS construits sur JmsComponent et JmsBinding : camel-amqp, camel-activemq et camel-activemq6. Il s'agit d'un contournement du correctif CVE-2026-40860 plutôt que d'une faille dans celui-ci. Ce problème affecte Apache Camel : de 3.0.0 avant 4.14.8, de 4.15.0 avant 4.18.3, de 4.19.0 avant 4.21.0 ; Apache Camel : de 3.0.0 avant 4.14.8, de 4.15.0 avant 4.18.3, de 4.19.0 avant 4.21.0. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.21.0, qui corrige le problème. Si les utilisateurs sont sur le flux de versions LTS 4.14.x, il leur est suggéré de passer à 4.14.8. Si les utilisateurs sont sur le flux de versions 4.18.x, il leur est suggéré de passer à 4.18.3. Après la mise à niveau, le traitement des ObjectMessage JMS est désactivé par défaut dans camel-jms, camel-sjms et les composants de la famille JMS (une nouvelle option objectMessageEnabled est définie par défaut sur false au niveau du composant et du point de terminaison), de sorte qu'un ObjectMessage entrant — y compris une charge utile DefaultExchangeHolder — n'est plus désérialisé à moins que l'option ne soit explicitement activée ; ne définissez objectMessageEnabled=true que lorsque la destination JMS consommée est alimentée exclusivement par des producteurs de confiance. Pour les déploiements qui ne peuvent pas effectuer de mise à niveau immédiatement, restreignez l'accès en publication aux files d'attente et aux sujets consommés par Camel aux producteurs de confiance via l'autorisation du courtier JMS, et n'exposez pas les consommateurs JMS qui mappent les corps d'ObjectMessage vers des réseaux non fiables ; une liste d'autorisation de désérialisation du fournisseur JMS n'atténue pas ce contournement spécifique car la charge utile conçue n'utilise que des classes universellement fiables.