CVE-2026-66907 in Camel
Résumé
par VulDB • 25/08/2026
Vulnérabilité de traversée de chemin relatif dans le composant Google Storage d'Apache Camel.
Cette vulnérabilité affecte Apache Camel : des versions 4.0.0 avant la 4.14.9, des versions 4.15.0 avant la 4.18.4 et des versions 4.19.0 avant la 4.22.0.
Le consommateur camel-google-storage télécharge les objets de Google Cloud Storage sur le système de fichiers local lorsque l'option downloadFileName est définie. Cette option est documentée comme étant un dossier ou un nom de fichier, et lorsque sa valeur ne contient aucun jeton d'expression (token), le consommateur construit la destination locale en ajoutant le nom de l'objet à cette valeur : evaluateFileExpression définit l'en-tête Exchange file-name 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 applique FileUtil.stripPath. La chaîne résultante est transmise directement à new File(result) et blob.downloadTo(file.toPath()) sans normalisation lexicale ni vérification que la destination reste dans le répertoire configuré. Le nom de l'objet n'est pas une donnée contrôlée par le routeur : le consommateur liste le bucket, itère sur chaque blob retourné 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 appliquée que si elle a été explicitement définie. Les noms d'objets Google Cloud Storage sont des clés UTF-8 opaques stockées et listées exactement telles qu'écrites par le service, sans canonicalisation côté serveur, et une barre oblique avant (/) est uniquement une convention d'affichage pour les pseudo-répertoires ; ainsi, un nom de clé contenant des segments de répertoire parent survit au cycle complet intact. Un nom d'objet contenant de tels segments résout donc vers un emplacement en dehors du répertoire downloadFileName configuré, permettant à quiconque pouvant influencer les noms présents dans le bucket consommé de faire créer ou écraser par Camel un fichier à l'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 entraîner une escalade au-delà de la simple perte d'intégrité de ce fichier. L'option downloadFileName est un paramètre consommateur ordinaire et ne porte aucun marqueur de sécurité ; rien n'a donc signalé aux utilisateurs que sa valeur n'était pas appliquée comme limite de confinement (containment boundary). Le défaut concerne uniquement le consommateur ; le producteur n'a pas de sink 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 du stockage Azure - contraignaient déjà leurs téléchargements locaux au répertoire configuré à l'aide d'une vérification de limite de segment de chemin ; camel-google-storage était le dernier sink de téléchargement de magasin d'objets non couvert 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 utilisent les versions LTS de la série 4.14.x, il leur est suggéré de passer à la 4.14.9. Si les utilisateurs sont sur la branche des versions 4.18.x, il leur est suggéré de mettre à niveau vers la 4.18.4. Pour les déploiements qui ne peuvent pas effectuer une mise à niveau immédiate, définissez l'option filter sur une expression régulière n'acceptant que des noms d'objets simples à segment unique, afin qu'un nom comportant 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 est laissée non définie et que l'expression correspond au nom complet de l'objet. Alternativement, attribuez à downloadFileName une expression explicite qui ne transmet pas le chemin distant, par exemple basée sur ${file:onlyname} plutôt que sur le ${file:name} implicite, en gardant à l'esprit qu'un downloadFileName contenant une expression est traité comme contrôlé par le routeur et n'est pas couvert par la vérification de confinement ajoutée dans la correction. En tant que défense en profondeur (defense in depth), traitez les noms d'objets dans tout bucket accessible en écriture externe comme des entrées non fiables et ne dérivez pas de chemins du système de fichiers local à partir de ceux-ci.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.