CVE-2026-95628
Apache Camel : la validation du chemin d'argument CLI personnalisé de Camel-Docling ne rejette pas les chemins absolus (correctif incomplet de CVE-2026-40047)
- Publié
- 26 oct. 2026
- Mise à jour
- 26 oct. 2026
- Attribution de CNA
- apache
- Preuve observée
- 30 oct. 2026
CVSS primaire
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:LFaible · 30 prochains jours
- Percentile
- 26,9 %
- Date du modèle
- 2 nov. 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 limitation incorrecte d'un nom de chemin à un répertoire restreint (« Path Traversal ») dans le composant Apache Camel Docling. Ce problème affecte Apache Camel : de 4.15.0 avant 4.18.5, de 4.19.0 avant 4.22.2. DoclingProducer construit la ligne de commande de l'outil externe docling et y ajoute les arguments personnalisés fournis dans l'en-tête CamelDoclingCustomArguments, une liste de chaînes dont les indicateurs ont été restreints à une liste d'autorisation par le correctif de CVE-2026-40047. Ce correctif a également introduit validatePathSafety pour maintenir les valeurs d'arguments de type chemin à l'intérieur du répertoire prévu, mais la méthode ne recherchait que la traversée relative : elle rejetait une valeur contenant une séquence de traversée telle que ../ et une valeur dont la forme normalisée contenait encore un élément ... Elle ne vérifiait jamais si une valeur était un chemin absolu, et un chemin absolu sans segments de traversée ne contient ni l'un ni l'autre, il passait donc inchangé. Chaque valeur de type chemin passait par cette vérification, qu'elle soit un élément de liste distinct suivant son indicateur ou qu'elle soit attachée à l'indicateur après un signe égal, de sorte qu'un chemin absolu était accepté sous l'une ou l'autre forme, par exemple comme répertoire donné à l'indicateur autorisé --artifacts-path, qui indique à docling où trouver ses artefacts de modèle. Une telle valeur atteignait la ligne de commande docling telle quelle, de sorte qu'une partie capable de choisir les arguments personnalisés pouvait pointer le processus docling vers n'importe quel répertoire auquel le processus Camel peut accéder, en dehors du répertoire de travail dans lequel la vérification était censée maintenir les valeurs de chemin, ce qui est le résultat que le correctif de CVE-2026-40047 visait à empêcher. Seul le mode CLI, qui est le mode par défaut, transmet des arguments personnalisés à docling. L'en-tête appartient à l'espace de noms des en-têtes Camel, que les consommateurs appliquant le filtrage d'en-têtes par défaut de Camel, tels que les consommateurs JMS et Kafka, suppriment des messages entrants, de sorte que le problème est atteint lorsqu'une route transmet des valeurs influencées de l'extérieur dans l'en-tête ou lorsqu'un consommateur mappe les en-têtes entrants sans ce filtrage. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.23.0, qui corrige le problème. Si les utilisateurs sont sur la branche des versions 4.22.x, il leur est suggéré de mettre à niveau vers 4.22.2. Si les utilisateurs sont sur la branche des versions 4.18.x, il leur est suggéré de mettre à niveau vers 4.18.5. Les lignes de versions 4.15.x à 4.17.x et 4.19.x à 4.21.x ont atteint leur fin de vie avant la résolution de ce problème et ne recevront pas de correctif, les déploiements sur celles-ci doivent donc migrer vers une version prise en charge. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, ne construisez pas l'en-tête CamelDoclingCustomArguments à partir de valeurs provenant de l'extérieur du déploiement, supprimez cet en-tête des messages arrivant de l'extérieur avant qu'ils n'atteignent un point de terminaison docling, et assurez-vous que les consommateurs qui mappent les en-têtes de messages entrants suppriment l'espace de noms des en-têtes Camel, afin que seule la route elle-même choisisse les arguments personnalisés.
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.