CVE-2026-94386

Résumé

Vulnérabilité d'utilisation d'un cache contenant des informations sensibles dans le composant Oauth d'Apache Camel. Ce problème affecte Apache Camel : de 4.19.0 avant 4.22.2. OAuthClientCredentialsTokenResolver obtient des jetons bearer OAuth 2.0 via le grant client credentials pour le compte des composants qui authentifient leurs appels sortants avec un profil OAuth nommé, tels que camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat et les composants IBM watsonx, ainsi que des applications qui appellent directement le SPI OAuthClientAuthenticationFactory. Il conservait les jetons obtenus dans un cache statique partagé par chaque instance de resolver et chaque CamelContext de la JVM, et indexait ce cache uniquement sur le endpoint de jeton et le client ID, bien que la requête de jeton transporte également le client secret et le scope demandé. Deux profils qui partagent un endpoint de jeton et un client ID mais demandent des scopes différents, ou s'authentifient avec des client secrets différents, étaient donc associés à la même entrée de cache : le profil qui résolvait un jeton en premier remplissait l'entrée, et l'autre profil recevait ensuite ce jeton, sans qu'aucune requête de jeton ne soit effectuée selon sa propre configuration, tant que le jeton restait valide. La mise en cache des jetons est activée par défaut, et pointer plusieurs profils vers un même client d'un fournisseur d'identité relève d'un usage ordinaire du support des profils plutôt que d'une activation volontaire d'un paramètre non sécurisé. Le résultat est une requête sortante qui transporte un jeton émis pour le scope d'un autre profil, ce qui peut accorder une autorité plus large que celle pour laquelle le profil appelant était configuré, ou atteindre un service pour lequel le jeton n'a pas été émis ; avec les fournisseurs d'identité qui dérivent l'audience d'un jeton à partir du scope demandé, un scope différent peut signifier un jeton pour un service entièrement différent. Un profil configuré avec un client secret différent recevait de même le jeton obtenu avec l'autre secret, sans s'authentifier avec le sien. Les profils sont configurés par le déploiement, qui est de confiance, donc aucune entrée non fiable n'atteint le cache : la partie qui en bénéficie est le service qui reçoit un jeton qu'il n'était pas censé recevoir, lequel, s'il est hostile ou compromis, peut rejouer ce jeton dans son scope. Atteindre le problème nécessite un déploiement qui définit plus d'un profil partageant un endpoint de jeton et un client ID tout en différant par le scope ou le client secret. 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.2. Les lignes de versions 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, de sorte que les déploiements sur celles-ci doivent migrer vers une version prise en charge. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, désactiver la mise en cache des jetons sur chaque profil OAuth qui partage un endpoint de jeton et un client ID avec un autre profil, en définissant camel.oauth.NAME.cache-tokens=false pour un profil nommé ou camel.oauth.cache-tokens=false pour celui par défaut, afin que chaque résolution demande un jeton avec le scope et le client secret propres à ce profil, au prix d'une requête de jeton à chaque résolution. Alternativement, enregistrer un client distinct auprès du fournisseur d'identité pour chaque profil qui nécessite un scope ou un client secret différent, afin qu'aucun de ces deux profils ne partage un client ID.