
Reproducteurs de preuve de concept pour la traversée de chemin de camel-google-storage d'Apache Camel (CVE-2026-66907), démontrant l'écriture arbitraire de fichiers via downloadFileName, avec les détails des versions concernées et corrigées.
downloadFileName traversée de cheminReproducteurs de preuve de concept exécutables pour la même vulnérabilité Apache Camel, un par runtime :
| Runtime | Répertoire | Stack |
|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-google-storage 4.18.2 |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.36.0 + Camel Quarkus 3.36.0 (embarque Camel 4.20.0) |
Les deux sont des versions affectées (le problème est corrigé dans les versions 4.14.9 / 4.18.4 / 4.22.0), et les deux illustrent le même
défaut : le consommateur camel-google-storage télécharge les objets du bucket vers le système de fichiers local lorsque downloadFileName
est un répertoire, en construisant la cible locale en y ajoutant le nom de l'objet distant
(downloadFileName + "/${file:name}"). Le jeton ${file:name} renvoie le nom de l'objet tel quel (contrairement à
${file:onlyname}, qui supprime le chemin), et le résultat était passé à new File(result) /
blob.downloadTo(file.toPath()) sans normalisation et sans vérification que la destination restait dans le
répertoire configuré. Le nom de l'objet n'est pas contrôlé par la route — le consommateur liste le bucket et télécharge chaque
objet — si bien qu'un objet dont le nom contient des segments ../ est écrit en dehors de downloadFileName (CWE-22, traversée
de chemin → écriture arbitraire de fichier).
Chaque sous-répertoire est autonome (son propre Dockerfile, son docker-compose.yml qui démarre un
émulateur fake-gcs-server, et son README). En résumé, pour l'un ou l'autre :
cd camel-spring-boot # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Sortie attendue sur une version affectée (les deux variantes) :
Files inside the intended download directory /app/downloads:
- report.txt
File written OUTSIDE it, at /tmp/pwned-66907.txt: true
content: PWNED via path traversal — CVE-2026-66907
>>> PROVEN: the object name's ../ segments escaped the configured downloadFileName directory ... : true
| Propriété | Valeur |
|---|---|
| Composant | camel-google-storage (Spring Boot : camel-google-storage-starter ; Quarkus : camel-quarkus-google-storage) |
| CWE | CWE-22 (Limitation incorrecte d'un nom de chemin à un répertoire restreint — Traversée de chemin) |
| Vecteur d'attaque | Un objet du bucket dont le nom contient des segments ../, téléchargé par le consommateur avec downloadFileName défini sur un répertoire |
| Impact | Écriture arbitraire de fichier en dehors du répertoire de téléchargement configuré |
| Versions affectées | De 4.0.0 avant 4.14.9, de 4.15.0 avant 4.18.4, de 4.19.0 avant 4.22.0 |
| Versions corrigées | 4.14.9, 4.18.4, 4.22.0 |
| JIRA | CAMEL-24279 |
| Crédit | n0mi1k |
Avis de sécurité : https://camel.apache.org/security/CVE-2026-66907.html
Le consommateur normalise désormais le chemin résolu et s'assure qu'il reste dans le répertoire downloadFileName
configuré (via GoogleCloudStorageFileNameHelper.assertWithinDirectory), rejetant les noms d'objets qui en sortiraient.
Le docker-compose.yml exécute fake-gcs-server avec -backend memory. Les noms d'objets sont alors conservés comme des clés de map
opaques, si bien qu'un nom contenant ../ est préservé ; le backend filesystem par défaut résoudrait les ../ et
l'objet ne serait pas listable.
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 à niveau la résout. Le fichier écrit est un
marqueur bénin sous /tmp. N'utilisez pas ce contenu contre des systèmes que vous ne possédez pas ou que vous n'exploitez pas.