CVE-2026-66907

Résumé

Vulnérabilité de traversée de chemin relatif dans le composant Google Storage d'Apache Camel. Ce problème affecte Apache Camel : de 4.0.0 avant 4.14.9, de 4.15.0 avant 4.18.4, de 4.19.0 avant 4.22.0. Le consommateur camel-google-storage télécharge les objets Google Cloud Storage vers le système de fichiers local lorsque l'option downloadFileName est définie. Cette option est documentée comme un dossier ou un nom de fichier, et lorsque sa valeur ne contient aucun jeton d'expression, le consommateur construit la destination locale en y ajoutant le nom de l'objet : evaluateFileExpression définit l'en-tête file-name de l'Exchange sur le nom de l'objet distant et évalue downloadFileName + "/${file:name}". Le jeton ${file:name} renvoie l'en-tête file-name tel quel, contrairement à ${file:onlyname}, qui lui applique FileUtil.stripPath. La chaîne résultante était passée directement à new File(result) et à blob.downloadTo(file.toPath()) sans normalisation lexicale ni vérification que la destination restait dans le répertoire configuré. Le nom de l'objet n'est pas une donnée contrôlée par la route : le consommateur liste le bucket, itère sur chaque blob renvoyé et crée un échange par objet à partir de blob.getBlobId().getName() tel quel, et l'option filter qui pourrait restreindre ces noms n'est pas appliquée du tout à moins qu'elle n'ait été explicitement définie. Les noms d'objets Google Cloud Storage sont des clés UTF-8 opaques que le service stocke et liste exactement telles qu'elles sont écrites, sans canonicalisation côté serveur, et une barre oblique n'est qu'une convention d'affichage pour les pseudo-répertoires ; une clé contenant des segments de répertoire parent survit donc intacte à un aller-retour. Un nom d'objet contenant de tels segments se résolvait donc vers un emplacement en dehors du répertoire downloadFileName configuré, permettant à toute personne capable d'influencer les noms présents dans le bucket consommé de faire créer ou écraser par Camel un fichier à un emplacement de son choix, avec les privilèges du processus Camel. Selon ce que le processus peut écrire, l'écrasement d'un fichier en dehors du répertoire de téléchargement peut dépasser la perte d'intégrité de ce fichier. L'option downloadFileName est un paramètre de consommateur ordinaire et ne porte aucun marqueur de sécurité, donc rien ne signalait aux utilisateurs que sa valeur n'était pas appliquée comme frontière de confinement. Le défaut concerne uniquement le consommateur ; le producteur n'a pas de sortie de téléchargement vers fichier. Les autres consommateurs de téléchargement de fichiers de Camel — camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files et les chemins de téléchargement Azure Storage — limitaient déjà leurs téléchargements locaux au répertoire configuré à l'aide d'une vérification de frontière par segment de chemin ; camel-google-storage était la dernière sortie de téléchargement de magasin d'objets non couverte par ce travail. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.22.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 à la version 4.14.9. Si les utilisateurs sont sur le flux de versions 4.18.x, il leur est suggéré de passer à la version 4.18.4. Pour les déploiements qui ne peuvent pas effectuer la mise à niveau immédiatement, définissez l'option filter sur une expression régulière qui n'accepte que les noms d'objets simples à segment unique, afin que tout nom contenant un séparateur de chemin ou un segment de répertoire parent soit exclu avant la création d'un échange ; notez qu'aucun filtrage n'est appliqué lorsque l'option n'est pas définie et que l'expression est comparée à la totalité du nom de l'objet. Alternativement, donnez à downloadFileName une expression explicite qui ne transmet pas le chemin distant, par exemple une expression basée sur ${file:onlyname} plutôt que sur ${file:name} implicite, en gardant à l'esprit qu'un downloadFileName contenant une expression est considéré comme contrôlé par l'auteur de la route et n'est pas couvert par la vérification de confinement ajoutée dans le correctif. Comme défense en profondeur, traitez les noms d'objets de tout bucket accessible en écriture externe comme des entrées non fiables et n'en dérivez pas de chemins du système de fichiers local.