Le projet Ceph a publié Tentacle 20.2.4 et Squid 19.2.6 afin de corriger quatre vulnérabilités de sécurité affectant CephX, le RADOS Gateway (RGW) et les moniteurs du cluster. Le projet lui-même qualifie ces versions de hotfixes et recommande aux opérateurs de procéder à une mise à jour dès que possible. L’intervention ne se limite pas simplement à l’installation des nouveaux paquets : l’une des failles exige une attention particulière à la rotation des clés CephX.

Les vulnérabilités de Ceph en 30 secondes

• Ceph a corrigé 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 certaines crédences valides de faible niveau.
• La solution introduit un nouveau type de clé aes256k.
• RGW présente également des problèmes liés aux tokens STS et aux signatures SigV4.
• Cephadm automatise une grande partie de la rotation des clés de service, mais ne gère généralement pas les crédences des clients.

La mise à jour nécessite un certain planification car la CVE-2025-30156 concerne les versions antérieures de Ceph utilisant des crédences avec le type de clé aes. Cependant, cela ne signifie pas que tout cluster Ceph puisse être attaqué directement depuis Internet : le scénario décrit requiert une clé CephX valides avec de faibles privilèges et un accès au réseau du cluster.

Ainsi, l’urgence pratique peut varier considérablement entre une infrastructure entièrement contrôlée par un seul administrateur et un environnement où des crédences sont distribuées à des clients, tenants ou systèmes moins fiables.

Quatre vulnérabilités et un changement important dans CephX

La mise à jour traite de quatre problématiques différentes.

La vulnérabilité nécessitant le changement le plus profond concerne CVE-2025-30156.

CephX est le système d’authentification utilisé par Ceph pour vérifier l’identité des clients et des composants du cluster. La documentation technique du projet explique que l’ancien schéma emploie AES-128-CBC sans authentification, sans HMAC et avec un vecteur d’initialisation fixe.

Cette combinaison peut permettre de modifier certains données cryptées sans que le système détecte la manipulation. Dans les conditions décrites par le projet, un attaquant disposant d’une crédence CephX valide avec peu de privilèges et d’un accès au réseau pourrait potentiellement falsifier des crédences avec un périmètre de permissions différent, y compris des crédences administratives.

La solution ne se limite pas à une simple correction de lignes de code. Ceph introduit pour la première fois un nouveau type de clé pour les crédences CephX : aes256k.

Ce dernier repose sur AES256-CTS-HMAC-SHA384-192, un protocole basé sur la RFC 8009 qui intègre une authentification du message et d’autres protections absentes du système précédent. Les nouvelles installations utiliseront ce type sûr, tandis que les versions existantes conserveront initialement leur compatibilité avec les crédences antérieures pour permettre une migration progressive.

Mettre à jour Ceph ne suffit pas : il faut aussi examiner les clés

Voici un point essentiel à considérer pour les administrateurs avant de procéder à l’entretien.

Après installation des nouvelles versions, il sera possible de voir apparaître des alertes et erreurs de santé liées aux crédences anciennes. Ceph indique que pendant le processus, six nouveaux états de santé ont été ajoutés, spécifiquement pour détecter des configurations utilisant encore les mécanismes antérieurs.

Par exemple, AUTH_INSECURE_SERVICE_KEY_TYPE signale des crédences de service utilisant toujours des types de clés considérés comme non sécurisés, tandis que AUTH_INSECURE_CLIENT_KEY_TYPE concerne de même les crédences des clients.

Ainsi, voir des alertes après une mise à jour ne signifie pas forcément que celle-ci a échoué. Cela peut simplement indiquer que le cluster détecte des crédences en attente de migration.

La procédure exacte dépend également de la configuration du déploiement de Ceph.

Cephadm automatise la rotation des clés de service, mais ne gère généralement pas les crédences des clients. Rook automatise aussi une partie du processus, notamment la rotation de certaines crédences client, avec quelques exceptions.

Les clusters installés via des paquets nécessitent une procédure plus manuelle et prudente. La documentation officielle décrit une migration progressive où l’on active aes256k, le définit comme chiffrement privilégié, et on procède à la rotation des crédences des différents services, puis enfin des crédences des clients compatibles.

L’adaptation de ces crédences nécessite une attention particulière.

Ceph indique que le support du nouveau type de clé dans le client du noyau Linux a débuté en Linux 7.0, avec des backports pour CentOS Stream 9 et 10. Les administrateurs doivent également vérifier si leur distribution supporte cette nouvelle méthode via leurs propres paquets avant de procéder à la rotation des crédences des clients du noyau.

Cela permet de maintenir temporairement les crédences précédentes, notamment dans les systèmes legacy, mais entraîne aussi l’apparition de nouveaux avertissements de sécurité.

RGW nécessite aussi une attention particulière

Les autres vulnérabilités rendent la mise à jour particulièrement importante pour les organisations utilisant Ceph comme plateforme de stockage objet compatible S3.

CVE-2026-39944 concerne les tokens de session STS de RGW et possède une origine cryptographique partagée avec le problème découvert dans CephX.

Dans ces environnements, la simple installation de la mise à jour ne résout pas forcément tout. Les opérateurs doivent examiner les tokens existants et achever leur migration vers la nouvelle norme cryptographique.

Il existe également CVE-2026-54330, liée à la vérification des signatures SigV4 utilisées par RGW. Après correction, RGW rejettera toute requête SigV4 dont les en-têtes host et x-amz- ne sont pas correctement inclus dans la signature.

Une considération spécifique concerne surtout les déploiements multisite.

Le client REST utilisé précédemment par Ceph multisite pouvait générer des requêtes désormais rejetées. Ceph recommande de configurer temporairement rgw_sigv4_insecure=true avant la mise à jour de multisite, puis de rétablir la configuration à false une fois la migration terminée sur tous les clusters.

Enfin, CVE-2026-50152 affecte le Moniteur et concerne un problème d’autorisation. Le projet conseille d’évaluer la possible exposition des secrets stockés et, dans les déploiements administrés via cephadm, recommande de faire tourner la clé SSH utilisée par ce système. La documentation pour la rotation d’autres secrets n’était pas encore prête au moment de la publication de cet avis.

Les quatre vulnérabilités ont été corrigées le 19 août 2026 avec Squid 19.2.6 et Tentacle 20.2.4. Pour les installations anciennes, il est conseillé d’étudier l’évolution vers une branche actuellement maintenue, plutôt que de supposer que tous les backports seront rapidement disponibles.

Ce changement est également pertinent au-delà de ces quatre CVE. L’introduction de aes256k représente une modification peu courante dans un composant aussi basique que les crédences d’authentification entre composants Ceph. C’est pourquoi cette opération doit être envisagée comme une mise à jour logicielle accompagnée d’une migration de crédences, notamment 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 également vérifier et faire migrer leurs crédences CephX en suivant la procédure recommandée.

Cephadm effectue-t-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 généralement ne gère pas les crédences clients. Rook automatise aussi une partie de ce processus, notamment la rotation de certaines crédences clients, avec quelques exceptions.

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

Le scénario documenté nécessite de disposer d’une clé CephX valide avec faibles privilèges et d’un accès au réseau du cluster. L’exposition est donc particulièrement critique dans les environnements où des crédences sont partagées avec des utilisateurs, tenants ou systèmes externes.