CVE-2026-79983

Résumé

Vulnérabilité de limitation incorrecte d'un nom de chemin à un répertoire restreint (« Path Traversal ») dans le composant FTP d'Apache Camel. Ce problème affecte Apache Camel : de 4.0.0 avant 4.18.5, de 4.19.0 avant 4.22.1. Les consommateurs de fichiers distants 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 la liste 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 repris 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 liste qui n'est pas un segment de chemin unique se résolvait donc vers un chemin situé 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 de l'endpoint. Un nom issu d'une liste 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 constituait l'autre moitié de cette surface. Cet artefact fournit les schémas ftp, ftps et sftp, tous affectés. Le rapporteur a démontré le problème de bout en bout contre un endpoint ftp, en pilotant une route Camel avec un serveur malveillant dont la réponse LIST nommait un fichier en dehors du répertoire interrogé. Mettez à niveau vers Apache Camel 4.23.0, qui corrige le problème. Les utilisateurs du flux de versions 4.22.x doivent mettre à niveau vers 4.22.1. Les utilisateurs du flux de versions LTS 4.18.x doivent mettre à 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.