oscerd/cve-2026-85300Reproducteur exécutable Spring Boot et Quarkus pour CVE-2026-85300, démontrant que camel-pqc écrit des clés privées avec des permissions de fichiers permissives dérivées de l'umask et vérifiant le correctif.
Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel où le FileBasedKeyLifecycleManager de camel-pqc
écrivait le matériel de clé généré sur le disque avec les permissions produites par l'umask par défaut du processus,
plutôt que de restreindre le fichier à son propriétaire. Sur un hôte dont l'umask autorise la lecture par le groupe ou par tous (le
022 courant), la clé privée non chiffrée était lisible par d'autres comptes locaux. L'exposition concerne une partie locale
plutôt que l'expéditeur distant, mais là où elle s'applique, la conséquence est totale : la possession de la clé privée
compromet toutes les signatures et tous les échanges de clés que le déploiement effectue avec elle.
| Runtime | Répertoire | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-pqc 4.22.0 (affecté ; corrigé en 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-pqc (Camel 4.22.0, affecté ; contrôle corrigé CQ 3.40.0 / Camel 4.22.1) |
Les deux modules démontrent le comportement affecté ainsi que le comportement corrigé. Les deux s'exécutent sous umask 022 (la valeur par défaut courante),
ce qui constitue la prémisse de la faille.
Le pilote utilise le véritable FileBasedKeyLifecycleManager : il stocke une paire de clés RSA dans un répertoire fraîchement créé
(manager.storeKey("k1", keyPair, new KeyMetadata("k","RSA"))) puis lit les permissions POSIX du fichier
k1.private.json écrit.
rw-r--r-- (0644) sous umask 022 — de sorte que le groupe
et les autres peuvent lire la clé privée non chiffrée.rw------- (0600, propriétaire uniquement) quel que soit l'umask.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: rw-r--r-- private key; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
umask 022 && java -jar target/cve-2026-85300-pqc-key-permissions-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: rw------- ; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.22.0): rw-r--r-- private key
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
umask 022 && java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: rw-------
| Propriété | Valeur |
|---|---|
| Composant | camel-pqc (FileBasedKeyLifecycleManager.storeKey) |
| CWE | CWE-276 (Permissions par défaut incorrectes) |
| Gravité | MOYENNE |
| Vecteur d'attaque | Un compte local capable de lire le répertoire des clés sur un hôte dont l'umask est permissif (par ex. 022) |
| Impact | Divulgation de la clé privée non chiffrée à d'autres comptes locaux |
| Versions affectées | De 4.12.0 avant 4.18.5, de 4.19.0 avant 4.22.1 |
| Versions corrigées | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24447 |
| Crédit | Claude Security Scan Tool |
Avis : https://camel.apache.org/security/CVE-2026-85300.html
Le module Quarkus affecté est construit sur CQ 3.39.0 (Camel 4.22.0) :
camel-quarkus-pqccorrespond pour la première fois à une version de Camel affectée à cet endroit (CQ 3.29.0 / Camel 4.15.0 est antérieur au gestionnaire de cycle de vie des clés basé sur des fichiers utilisé ici).
FileBasedKeyLifecycleManager restreint désormais le répertoire des clés et chaque
fichier de clé privée à leur propriétaire (rwx------ / rw------- via setPosixFilePermissions, avec un repli sur java.io.File
pour les systèmes de fichiers non POSIX) avant l'écriture, et resserre les permissions d'un fichier de clé préexistant lisible par tous lors d'une réécriture
(le fichier est tronqué, non recréé, il conserverait donc sinon les anciennes permissions). Tout matériel de clé déjà écrit
avec des permissions permissives doit être considéré comme exposé et faire l'objet d'une rotation.
Placez le répertoire des clés sur un chemin que seul le compte de service peut traverser et resserrez l'umask du processus ; considérez toute clé déjà écrite avec des permissions permissives comme exposée et effectuez sa rotation.
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 paire de clés RSA est générée en cours de processus dans un répertoire temporaire et supprimée après la vérification. N'utilisez pas ce matériel contre des systèmes que vous ne possédez pas ou n'exploitez pas.