CVE-2026-66908

Résumé

Vulnérabilité d'authentification inappropriée dans le composant Platform HTTP Main d'Apache Camel. Ce problème affecte Apache Camel : de 4.8.0 à avant 4.22.0. Le serveur HTTP intégré de camel-main peut protéger ses points de terminaison avec une authentification JWT, configurée via authenticationEnabled conjointement avec les propriétés du trousseau de clés JWT. JWTAuthenticationConfigurer.buildJwtOptions renvoyait null quand ni jwtIssuer ni jwtAudience n'étaient configurés, et l'appelant ignorait alors entièrement l'appel JWTAuthOptions.setJWTOptions, si bien que l'instance Vert.x JWTAuth était construite à partir du seul trousseau de clés. Il en résultait que les jetons entrants n'étaient contrôlés que pour la signature et l'expiration : les revendications iss et aud n'étaient pas validées du tout. Rien ne le signalait — le serveur démarrait normalement et n'affichait aucun avertissement — si bien qu'un déploiement configuré conformément à la documentation appliquait silencieusement moins de contrôles que ce que l'opérateur croyait avoir activé, et la documentation du composant elle-même présentait le contrôle de la signature et de l'expiration comme comportement par défaut, avec l'émetteur et l'audience comme simple option supplémentaire. Le serveur d'application et le serveur d'administration étaient tous deux affectés, car l'omission se trouvait dans chacun des deux chemins configureAuthentication. Tout jeton non expiré signé par une clé que le trousseau configuré approuve était donc accepté, quel que soit l'émetteur qui l'avait émis ou l'audience à laquelle il était destiné. La portée de cette faille dépend de l'ensemble de confiance du trousseau : lorsque la clé de signature appartient à un fournisseur d'identité partagé ou multi-tenant, un jeton légitimement émis pour une audience entièrement différente est accepté, tandis qu'un trousseau contenant un signataire dédié réduit la portée à la réutilisation de jetons émis pour d'autres services au sein du même domaine de confiance. Les options jwtIssuer et jwtAudience n'existaient pas avant la 4.21.0 ; sur les versions antérieures, il n'existait donc aucun moyen pris en charge de faire appliquer ces revendications. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.22.0, qui corrige le problème. À partir de la 4.22.0, le serveur refuse de démarrer lorsqu'un trousseau de clés JWT est configuré mais que ni jwtIssuer ni jwtAudience n'est défini, en nommant les propriétés concernées, et un déploiement qui ne souhaite véritablement que la validation de la signature et de l'expiration doit le déclarer explicitement au moyen de la nouvelle option jwtAllowMissingIssuerAndAudience, dont la valeur par défaut est false. Ce comportement n'est corrigé que dans la 4.22.0. Les versions 4.14.9 et 4.18.4 ne changent pas le comportement par défaut : elles ajoutent les options jwtIssuer et jwtAudience afin que les opérateurs sur ces lignes de maintenance puissent appliquer ces revendications par configuration, et une installation qui passe à la 4.14.9 ou à la 4.18.4 sans définir également au moins l'une de ces deux propriétés continue d'accepter tout jeton non expiré signé par une clé approuvée. Les utilisateurs de 4.14.x ou de 4.18.x devraient donc passer à la 4.14.9 ou à la 4.18.4, puis définir jwtIssuer, jwtAudience, ou les deux. Les versions allant de 4.8.0 jusqu'à 4.21.x incluse n'offrent aucun moyen d'appliquer ces revendications et devraient être migrées vers une version qui le permet. Indépendamment de la version, restreignez le trousseau de clés JWT au plus petit ensemble de confiance possible — idéalement un signataire dédié à ce service plutôt qu'une clé partagée de fournisseur d'identité — et, lorsqu'une passerelle valide déjà l'émetteur et l'audience devant le serveur, assurez-vous qu'elle ne puisse pas être contournée. Notes : Le ticket JIRA : https://issues.apache.org/jira/browse/CAMEL-24281 fait référence aux différents commits qui ont résolu le problème et fournit plus de détails. Le garde-fou fail-closed n'a pas pu être rétroporté. Les options jwtIssuer et jwtAudience n'ont elles-mêmes été introduites qu'en 4.21.0 via CAMEL-23525 ; sur camel-4.18.x et camel-4.14.x, il n'y avait donc rien qu'un opérateur puisse configurer pour satisfaire l'exigence, et le garde-fou aurait cassé tous les déploiements JWT sur ces branches, sans aucun recours possible.