oscerd/cve-2026-66907Reproducteurs 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.
| 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.