CVE-2026-78163
Apache Camel : la source d'entrée du corps de message non validé de Camel-Docling permet une falsification de requête côté serveur et une divulgation de fichiers locaux
- Publié
- 19 oct. 2026
- Mise à jour
- 19 oct. 2026
- Attribution de CNA
- apache
- Preuve observée
- 17 oct. 2026
CVSS primaire
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NRésumé
Falsification de requête côté serveur (SSRF), limitation incorrecte d'un nom de chemin à un répertoire restreint (« Path Traversal ») et exposition d'informations sensibles à un acteur non autorisé, vulnérabilité 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.1. DoclingProducer décidait de la signification d'un corps de message de type String en inspectant son préfixe. Un corps commençant par http:// ou https:// était transmis à Docling comme une URL distante à récupérer, un corps commençant par / ou contenant une barre oblique inverse était lu depuis le système de fichiers local, et tout le reste était écrit dans un fichier temporaire et converti comme contenu de document. Le mode était choisi implicitement et aucune option de point de terminaison ne permettait à l'auteur d'une route d'épingler le composant à une seule interprétation, de sorte qu'une route censée convertir n'importe quel texte arrivant dans le corps devenait silencieusement un récupérateur de ressources distantes ou un lecteur de fichiers locaux dès que le texte commençait par l'un de ces préfixes. La seule protection appliquée à la valeur dérivée était une vérification de taille, et cette vérification était enveloppée dans un test d'existence, de sorte qu'un chemin qui ne résolvait vers rien, ou vers un pseudo-fichier rapportant une taille de zéro, passait sans être vérifié du tout. Cinq sites d'appel atteignaient les deux sinks : le mode CLI ajoutait la valeur comme argument positionnel final du sous-processus docling, et le mode docling-serve la transmettait soit à HttpSource pour que le backend la récupère, soit à Files.readAllBytes afin que le contenu puisse être encodé en base64 et téléversé. Parce que le corps de l'échange n'est jamais filtré par un HeaderFilterStrategy, contrairement à l'espace de noms des en-têtes Camel, un expéditeur capable de placer du texte dans un message qu'une route transmet à un point de terminaison docling pouvait atteindre les deux sinks sans aucun opt-in du déploiement. 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.1. Si les utilisateurs sont sur la branche des versions 4.18.x, il leur est suggéré de mettre à niveau vers 4.18.5. La branche des versions 4.14.x et antérieures a atteint sa fin de vie avant que ce problème ne soit résolu et ne recevra pas de correctif, de sorte que les déploiements sur ces branches doivent migrer vers une version prise en charge. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, ne routez pas vers un point de terminaison docling des corps de message provenant de l'extérieur du déploiement, et faites passer le document via un corps typé tel que File, byte[] ou InputStream, ou via l'en-tête CamelDoclingInputFilePath, afin que le corps ne soit jamais soumis à une interprétation de préfixe.
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.