oscerd/cve-2026-78163Reproducteur de preuve de concept exécutable pour CVE-2026-78163 dans Apache Camel camel-docling, démontrant une SSRF et une divulgation de fichiers locaux via une entrée de corps String non validée, avec un contrôle sur une version corrigée.
Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel où DoclingProducer décidait de la
signification d'un corps de message String en inspectant son préfixe :
http:// ou https:// était transmis à Docling comme une URL distante à récupérer (SSRF), et/ (ou contenant une barre oblique inverse) était lu depuis le système de fichiers local (divulgation de fichiers).Le mode était choisi implicitement, sans option d'endpoint permettant de fixer une interprétation unique, et — contrairement au
namespace d'en-têtes Camel — le corps du message n'est jamais filtré par un HeaderFilterStrategy. Ainsi, une route qui signifie
« convertir le texte qui arrive dans le corps » devenait silencieusement un récupérateur de ressources distantes ou un lecteur de fichiers
locaux dès que le texte contrôlé par l'attaquant commençait par l'un de ces préfixes.
| Runtime | Répertoire | Stack | Démontre |
|---|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-docling 4.22.0 (affecté ; corrigé en 4.22.1) | SSRF et divulgation de fichiers, plus le contrôle avec le build corrigé |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-docling 3.29.0 (Camel 4.15.0, affecté) | divulgation de fichiers uniquement (voir note) |
Couverture des versions. Le sink de divulgation de fichiers locaux existe depuis l'introduction de camel-docling en 4.15.0 ; le sink d'URL distante a été ajouté en 4.16.0 avec le support de docling-serve. Le dernier Camel Quarkus (3.29.0) embarque Camel 4.15.0, son module ne démontre donc que la divulgation de fichiers. Le correctif est livré dans Camel 4.18.5 / 4.22.1 / 4.23.0 ; le module Spring Boot exécute à la fois le build affecté (4.22.0) et le build corrigé (4.22.1), il démontre donc aussi le comportement corrigé. Aucun Camel Quarkus publié n'embarque encore un Camel corrigé.
Aucun des deux reproducteurs n'a besoin d'une véritable installation de Docling : une minuscule CLI fausse docling (fake-docling/docling) remplace
le binaire et rend visible ce que le vrai ferait avec l'entrée fournie par le producer — récupérer une URL, ou lire un
fichier. Elle est bénigne : elle ne fait que renvoyer ce qu'on lui a demandé de traiter et journalise sa propre invocation. Le point de la CVE est
qu'un corps fourni par l'attaquant atteint cet argument, sans aucune activation explicite.
L'application Spring Boot exécute également un endpoint HTTP interne uniquement sur 127.0.0.1:9099 (seul le port 8080 est publié,
un client externe ne peut donc pas atteindre 9099 directement) et un fichier secret local. L'attaquant n'envoie que du texte :
http://127.0.0.1:9099/internal-secret → l'invocation docling côté serveur récupère
l'endpoint interne et son secret est renvoyé à l'appelant./tmp/cve-2026-78163-secret.txt → le fichier local est lu et renvoyé.Sur le build affecté, les deux réussissent ; sur le build corrigé, les deux sont rejetés avec une IllegalArgumentException
nommant l'option (allowUrlSource / allowFilePathSource) qui serait nécessaire pour les activer, et docling n'est
jamais invoqué.
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Sortie attendue sur le build Spring Boot affecté :
[1] SSRF — sending body = http://127.0.0.1:9099/internal-secret
>>> PROVEN SSRF: the server-side docling invocation fetched the attacker-controlled internal URL.
>>> internal victim saw: [GET /internal-secret]
>>> content returned to the caller:
| INTERNAL-SECRET-DATA (only reachable from inside the deployment)
[2] File disclosure — sending body = /tmp/cve-2026-78163-secret.txt
>>> PROVEN file disclosure: the attacker-named local file was read and returned.
| TOP-SECRET-FILE-CONTENT (local file an attacker should not be able to read)
| Propriété | Valeur |
|---|---|
| Composant | camel-docling (camel-docling-starter / camel-quarkus-docling) |
| CWE | CWE-918 (SSRF), CWE-22 (Path Traversal), CWE-200 (Information Exposure) |
| Sévérité | MOYENNE |
| Vecteur d'attaque | Un corps de message String transmis vers un endpoint docling, dont le préfixe sélectionne un sink de récupération d'URL ou de lecture de fichier ; le corps n'est pas soumis au HeaderFilterStrategy |
| Impact | Récupération côté serveur d'URL choisies par l'attaquant (services internes) et divulgation de fichiers locaux |
| Versions affectées | De 4.15.0 avant 4.18.5, de 4.19.0 avant 4.22.1 (divulgation de fichiers depuis 4.15.0 ; sink d'URL depuis 4.16.0) |
| Versions corrigées | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24422 |
| Crédit | Li Zhiyao (BUPT) |
Avis : https://camel.apache.org/security/CVE-2026-78163.html
Un corps String est désormais traité comme le document lui-même par défaut. Les deux interprétations de localisation sont devenues optionnelles via
de nouvelles options d'endpoint allowUrlSource et allowFilePathSource (toutes deux à false par défaut) ; un corps qui ressemble à une URL
ou à un chemin est sinon rejeté avec une IllegalArgumentException nommant l'option qui l'activerait. Une option supplémentaire
inputBaseDirectory confine les chemins d'entrée locaux à un répertoire configuré. Les corps typés (File, byte[],
InputStream) et l'en-tête CamelDoclingInputFilePath expriment déjà leur signification et ne sont pas soumis à restriction (mais restent
soumis à inputBaseDirectory).
Ne routez pas de corps de message d'origine externe vers un endpoint docling ; passez le document via un corps typé
(File, byte[], InputStream) ou l'en-tête CamelDoclingInputFilePath afin que le corps ne soit jamais soumis à une interprétation
par préfixe.
Ce dépôt est publié à des fins éducatives et défensives : pour aider les utilisateurs d'Apache Camel à comprendre la
vulnérabilité, vérifier s'ils sont affectés, et confirmer que la mise à jour la résout. La fausse CLI docling et
les « secrets » sont des fixtures locales inertes. N'utilisez pas ce matériel contre des systèmes que vous ne possédez pas ou n'exploitez pas.