CVE-2026-79986

Résumé

Vulnérabilité de limitation incorrecte d'un nom de chemin à un répertoire restreint (« Path Traversal ») dans le composant Apache Camel Azure Files. Ce problème affecte Apache Camel : de 4.0.0 avant 4.18.5, de 4.19.0 avant 4.22.1. Les consommateurs remote-file de Camel interrogent un répertoire sur un serveur distant et construisent le chemin distant absolu de chaque fichier en concaténant le répertoire configuré avec le nom de fichier rapporté dans le listing du répertoire du serveur. Cette concaténation (FtpUtils.absoluteFilePath et GenericFileConsumer) n'appliquait aucune normalisation lexicale et aucune vérification que le résultat restait à l'intérieur du répertoire interrogé, et le chemin résultant devenait l'opérande de chaque opération distante ultérieure sur le fichier : la récupération (FtpOperations.retrieveFile / SftpOperations, atteinte depuis GenericFileConsumer où le nom de récupération est pris verbatim depuis GenericFile.getAbsoluteFilePath), la suppression lorsque delete=true (GenericFileDeleteProcessStrategy), et le renommage lorsque move, preMove, moveFailed ou readLock=rename est configuré (GenericFileProcessStrategySupport et GenericFileRenameExclusiveReadLockStrategy). Ni isValidFile ni isMatched n'effectuaient de vérification de confinement. Une entrée de listing qui n'est pas un segment de chemin unique se résolvait donc vers un chemin en dehors du répertoire d'interrogation configuré, amenant Camel à lire, supprimer ou renommer des fichiers en dehors de celui-ci en utilisant les propres identifiants du point de terminaison. Un nom de listing n'est pas une donnée contrôlée par la route. Il est fourni par le serveur distant, et le canal de contrôle FTP ne transporte aucune protection d'intégrité, de sorte qu'un attaquant sur le chemin peut réécrire une réponse LIST sans détenir aucun identifiant ; un serveur compromis, malveillant ou multi-tenant, ou un serveur adossé à un système de fichiers virtuel, peut émettre un tel nom directement. La récupération est atteignable dans une configuration de consommateur par défaut, puisque les consommateurs distants téléchargent chaque fichier listé ; la suppression et le renommage nécessitent en outre l'une des options de disposition ci-dessus, toutes courantes. L'évasion du répertoire que Camel était configuré à interroger est inconditionnelle, tandis que l'évasion de la frontière du propre compte du serveur dépend en outre de si ce serveur confine le compte. L'option jailStartingDirectory, documentée comme restreignant Camel au répertoire de départ et activée par défaut, régissait les écritures du producteur et, depuis les travaux de confinement de localWorkDirectory, les téléchargements du consommateur vers le répertoire de travail local — mais elle ne contraignait pas cet opérande distant, de sorte que son nom et sa description revendiquaient une frontière qui n'était pas appliquée ici. Le même point d'entrée avait déjà été reconnu du côté local : le chemin de téléchargement localWorkDirectory a été contraint afin qu'un nom de fichier distant contenant des segments de répertoire parent ne puisse se résoudre en dehors du répertoire de travail local. L'opérande distant était la moitié restante de cette surface. Cet artefact fournit le schéma azure-files. Son consommateur dérive de la même classe de base RemoteFileConsumer et composait le chemin distant via un simple assistant de concaténation, héritant ainsi de la même résolution non contrainte. L'atteindre nécessite un nom de listing qui n'est pas un segment de chemin unique, ce que le service REST Azure Files ne renvoie normalement pas ; l'exposition a été corrigée sur la même base que les autres consommateurs remote-file plutôt qu'à partir d'une preuve de concept démontrée contre ce schéma. Effectuez la mise à niveau vers Apache Camel 4.23.0, qui corrige le problème. Les utilisateurs du flux de versions 4.22.x doivent effectuer la mise à niveau vers 4.22.1. Les utilisateurs du flux de versions LTS 4.18.x doivent effectuer la mise à niveau vers 4.18.5. Le flux 4.14.x a atteint sa fin de vie et ne reçoit pas ce correctif ; ses utilisateurs doivent passer à un flux de versions pris en charge.