Le projet Ceph a publié Tentacle 20.2.4 et Squid 19.2.6 pour corriger quatre vulnérabilités touchant CephX, le RADOS Gateway (RGW) et les moniteurs du cluster. Le projet qualifie lui-même ces versions de hotfixes et recommande aux opérateurs de mettre à jour dès que possible. L’intervention ne se limite pas à installer les nouveaux paquets : l’une des failles exige en plus une véritable rotation des clés CephX.

L’essentiel : Ceph corrige quatre CVE dans Tentacle 20.2.4 et Squid 19.2.6. La faille la plus large concerne CephX et peut permettre une élévation de privilèges à partir de crédences valides de faible niveau. La solution introduit un nouveau type de clé, aes256k. RGW présente aussi des problèmes liés aux tokens STS et aux signatures SigV4, et Cephadm automatise une bonne partie de la rotation des clés de service, mais gère rarement les crédences des clients.

La mise à jour demande une vraie planification, car la CVE-2025-30156 touche les versions antérieures de Ceph qui utilisent des crédences avec le type de clé aes. Cela ne veut pas dire que tout cluster Ceph est attaquable directement depuis Internet : le scénario décrit exige une clé CephX valide à faibles privilèges et un accès au réseau du cluster. L’urgence pratique varie donc énormément entre une infrastructure entièrement contrôlée par un seul administrateur et un environnement où des crédences circulent chez des clients, tenants ou systèmes moins fiables.

Quatre vulnérabilités, un changement structurel dans CephX

La CVE-2025-30156 impose le changement le plus profond. CephX est le système d’authentification qui vérifie l’identité des clients et des composants du cluster, et la documentation du projet explique que l’ancien schéma s’appuie sur AES-128-CBC sans authentification, sans HMAC et avec un vecteur d’initialisation fixe. Cette combinaison permet de modifier certaines données chiffrées sans que le système détecte la manipulation : dans les conditions décrites, un attaquant disposant d’une crédence CephX valide à faibles privilèges et d’un accès réseau pourrait falsifier des crédences avec un périmètre de permissions différent, y compris des crédences administratives.

La correction ne se limite pas à quelques lignes de code. Ceph introduit pour la première fois un nouveau type de clé pour les crédences CephX, aes256k, basé sur AES256-CTS-HMAC-SHA384-192 (RFC 8009), qui intègre une authentification du message et d’autres protections absentes du schéma précédent. Les nouvelles installations utiliseront directement ce type sûr, tandis que les déploiements existants gardent d’abord la compatibilité avec les anciennes crédences, le temps d’une migration progressive.

Mettre à jour ne suffit pas, il faut aussi migrer les clés

Point essentiel pour les administrateurs avant d’intervenir : après l’installation des nouvelles versions, des alertes et erreurs de santé liées aux anciennes crédences peuvent apparaître. Ceph a ajouté six nouveaux états de santé pour détecter spécifiquement les configurations qui utilisent encore les mécanismes antérieurs. Par exemple, AUTH_INSECURE_SERVICE_KEY_TYPE signale des crédences de service avec un type de clé jugé non sécurisé, et AUTH_INSECURE_CLIENT_KEY_TYPE fait la même chose côté clients. Voir ces alertes après une mise à jour ne signifie donc pas qu’elle a échoué, mais simplement que le cluster repère des crédences en attente de migration.

La procédure exacte dépend du mode de déploiement. Cephadm automatise la rotation des clés de service, mais gère rarement les crédences des clients. Rook automatise aussi une partie du processus, y compris la rotation de certaines crédences client, avec quelques exceptions. Les clusters installés via des paquets demandent une procédure plus manuelle : activer aes256k, le définir comme chiffrement privilégié, puis faire tourner les crédences des services avant celles des clients compatibles — une prudence comparable à celle recommandée pour la vulnérabilité KVM qui touche Proxmox VE et d’autres plateformes de virtualisation.

Ceph précise que le support du nouveau type de clé dans le client du noyau Linux a commencé avec Linux 7.0, avec des backports pour CentOS Stream 9 et 10. Les administrateurs doivent vérifier si leur distribution supporte cette méthode via ses propres paquets avant de lancer la rotation des crédences des clients du noyau, ce qui permet de garder temporairement les anciennes crédences dans les systèmes legacy, au prix de nouveaux avertissements de sécurité.

RGW demande, lui aussi, une attention particulière

Les autres vulnérabilités rendent la mise à jour tout aussi importante pour les organisations qui utilisent Ceph comme plateforme de stockage objet compatible S3. La CVE-2026-39944 touche les tokens de session STS de RGW et partage son origine cryptographique avec le problème découvert dans CephX : installer la mise à jour ne suffit pas, les opérateurs doivent aussi examiner les tokens existants et achever leur migration vers la nouvelle norme cryptographique.

La CVE-2026-54330 concerne la vérification des signatures SigV4 utilisées par RGW. Une fois corrigé, RGW rejette toute requête SigV4 dont les en-têtes host et x-amz- ne sont pas correctement inclus dans la signature, ce qui peut casser le client REST utilisé par les déploiements multisite. Ceph recommande de configurer temporairement rgw_sigv4_insecure=true avant la mise à jour multisite, puis de repasser à false une fois la migration terminée sur tous les clusters.

La CVE-2026-50152 affecte enfin le Moniteur, avec un problème d’autorisation. Le projet conseille d’évaluer l’exposition possible des secrets stockés et, dans les déploiements administrés via cephadm, de faire tourner la clé SSH utilisée par ce système. La documentation pour la rotation des autres secrets n’était pas encore prête au moment de la publication de cet avis. Ces quatre failles sont corrigées depuis le 19 août 2026 avec Squid 19.2.6 et Tentacle 20.2.4 ; pour les installations plus anciennes, mieux vaut envisager une montée vers une branche activement maintenue plutôt que compter sur des backports rapides, une logique qu’on retrouve dans la correction récente de neuf vulnérabilités par Intel via son microcode ou dans les deux failles critiques corrigées par Broadcom dans VMware vCenter.

Ce changement dépasse le cadre des quatre CVE. Introduire aes256k dans un composant aussi fondamental que les crédences d’authentification entre composants Ceph reste rare, ce qui explique pourquoi Ceph continue de s’imposer comme référence du stockage distribué tout en devant traiter cette opération comme une véritable migration de crédences, particulièrement dans les grands clusters, ceux multi-tenant ou avec de nombreux clients externes.

Questions fréquentes

Quelles versions de Ceph corrigent ces vulnérabilités ?

Les correctifs sont disponibles dans Ceph Tentacle 20.2.4 et Squid 19.2.6, publiés le 19 août 2026.

Une simple mise à jour des paquets Ceph suffit-elle ?

Pas forcément. La CVE-2025-30156 introduit le nouveau type de clé aes256k, donc les installations existantes doivent aussi vérifier et migrer leurs crédences CephX selon la procédure recommandée.

Cephadm fait-il la rotation automatique de toutes les clés ?

Non. Cephadm automatise la rotation des clés de service lors de la mise à jour, mais ne gère généralement pas les crédences clients. Rook automatise aussi une partie de ce processus, avec quelques exceptions.

Un cluster Ceph peut-il être attaqué directement via CVE-2025-30156 depuis Internet ?

Le scénario documenté exige une clé CephX valide à faibles privilèges et un accès au réseau du cluster. L’exposition est donc surtout critique là où des crédences sont partagées avec des utilisateurs, tenants ou systèmes externes.