CVE-2026-60093
Apache Camel : Camel-Azure-Storage-DataLake : l'opération downloadToFile a construit la cible de téléchargement local à partir du nom du chemin distant sans la contraindre au fileDir configuré
- Publié
- 24 août 2026
- Mise à jour
- 25 août 2026
- Attribution de CNA
- apache
- Preuve observée
- 24 août 2026
CVSS primaire
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NFaible · 30 prochains jours
- Percentile
- 17,7 %
- Date du modèle
- 21 sept. 2026
EPSS est une estimation statistique, et non une certitude ou une mesure d'impact. Combinez-le avec CVSS, le statut KEV, l'exposition et votre environnement.
Résumé
Vulnérabilité de traversée de chemin relatif dans le composant Azure-Storage Datalake 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 composant `camel-azure-storage-datalake` peut télécharger un fichier Azure Data Lake Storage Gen2 vers le système de fichiers local via son opération `downloadToFile`, en écrivant dans le répertoire désigné par l'option de point de terminaison `fileDir`. `DataLakeFileOperations.downloadToFile` construisait la cible locale en concaténant `fileDir` avec le nom du chemin distant exactement tel que le SDK Azure le rapportait (`new File(fileDir, fileClientWrapper.getFileName())`) et transmettait le résultat directement à l'appel de téléchargement du SDK, sans normalisation lexicale ni vérification que l'emplacement résolu restait dans `fileDir`. Le nom distant n'est pas une donnée contrôlée par la route : le consommateur énumère le système de fichiers dans `DataLakeConsumer.createBatchExchangesFromPath`, qui liste les chemins et crée un échange par entrée à partir de `PathItem.getName()` tel quel, sans appliquer de filtrage des noms par défaut. Un nom de chemin contenant des segments de répertoire parent se résolvait donc vers un emplacement situé en dehors du `fileDir` configuré, permettant à quiconque pouvant influencer les noms présents dans le système de fichiers Data Lake consommé d'amener Camel à créer ou écraser un fichier à un emplacement de son choix, avec les privilèges du processus Camel. Selon ce sur quoi le processus peut écrire, l'écrasement d'un fichier hors du répertoire de téléchargement peut dépasser la simple perte d'intégrité de ce fichier. L'option `fileDir` est un paramètre de configuration ordinaire du groupe `common` et ne porte aucun marqueur de sécurité, de sorte que rien ne signalait aux utilisateurs que sa valeur n'était pas appliquée comme limite de confinement. Les autres consommateurs de téléchargement de fichiers de Camel — `camel-file`, `camel-ftp`, `camel-smb`, `camel-mina-sftp` et `camel-azure-files` — limitaient déjà leurs téléchargements locaux au répertoire configuré à l'aide d'une vérification de limite par segment de chemin ; le chemin de téléchargement de `camel-azure-storage-datalake` n'était pas 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 se trouvent sur le flux de versions LTS 4.14.x, il leur est suggéré de passer à la version 4.14.9. S'ils se trouvent 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 être mis à niveau immédiatement, contraignez les noms sur lesquels le consommateur agira en utilisant l'option de point de terminaison `regex`, qui est appliquée à chaque nom de chemin listé comme une correspondance sur la chaîne complète, afin que seuls les noms simples à segment unique soient acceptés et que tout nom contenant un séparateur de chemin ou un segment de répertoire parent soit filtré avant la création d'un échange. Alternativement, évitez l'opération `downloadToFile` sur des systèmes de fichiers non fiables et écrivez la charge utile depuis la route sous un nom de fichier contrôlé par la route elle-même, plutôt que sous un nom issu du listing distant. À titre de défense en profondeur, traitez les noms d'objets de tout système de fichiers Data Lake accessible en écriture de l'extérieur comme des entrées non fiables et n'en dérivez pas de chemins du système de fichiers local.
Utilisation responsable
Utilisez les informations de vulnérabilité uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à tester. Kitploit renvoie aux métadonnées de la recherche publique et ne stocke pas de code d'exploitation ni de charges utiles malveillantes.