EN
en direct

Dell corrige six failles critiques de CSM qui livraient l’admin et le root des clusters Kubernetes

Dell a comblé six vulnérabilités de sévérité maximale dans ses Container Storage Modules, la couche qui relie ses baies PowerStore, PowerScale ou PowerFlex à Kubernetes. Sans aucune authentification, un attaquant récupère les identifiants d’administration des baies, obtient un root sur les nœuds et lit tous les Secrets : passez en CSM 1.18.0 sans attendre.

Une armoire murale de clés industrielles dans une salle serveurs sombre, une seule porte métallique forcée et vide, un seul porte-clés ambre posé sur le sol en béton.

2 octobre 2026. Dell publie un avis de sécurité qui comble six vulnérabilités critiques dans ses Container Storage Modules (CSM), la couche logicielle qui relie ses baies de stockage d’entreprise à Kubernetes. 2 octobre 2026. Deux de ces failles, logées dans le module CSM Authorization, laissent un attaquant non authentifié récupérer les identifiants d’administration de toutes les baies enregistrées et en prendre le contrôle administratif complet. 2 octobre 2026. Quatre autres failles offrent un root sur les nœuds du cluster, un admin sur le proxy d’autorisation, la forge de jetons d’authentification et la lecture de tous les Secrets. Pourquoi c’est important : CSM est la charnière entre le stockage d’entreprise et les applications conteneurisées — le compromettre, c’est compromettre à la fois les données et le plan de contrôle du cluster.

Une charnière devenue pivot privilégié

Container Storage Modules est la brique que Dell propose pour étendre les pilotes CSI standards de Kubernetes sur ses plateformes de stockage PowerStore, PowerScale, PowerFlex, PowerMax et Unity XT. Concrètement, CSM ajoute au-dessus du pilote CSI des services d’autorisation, de réplication, d’observabilité et de résilience. Le module CSM Authorization, au cœur de ces failles, gère qui a le droit d’accéder à quelle baie.

Ce positionnement fait de CSM un pivot privilégié. Il détient les identifiants des baies de stockage, il parle au serveur d’API Kubernetes, et il tourne souvent avec des privilèges élevés sur les nœuds. Une faille dans cette couche ne touche pas un service métier isolé : elle ouvre la porte à la fois au stockage et au cluster qui le consomme. C’est exactement le genre de composant que les équipes stockage installent, puis que les équipes Kubernetes oublient dans leur inventaire.

Deux failles qui livrent l’administration des baies

Les deux vulnérabilités les plus graves partagent la même cause racine, une absence d’authentification sur des fonctions critiques (CWE-306).

La première, CVE-2026-63688, laisse un attaquant distant non authentifié accéder aux identifiants d’administration du backend de stockage pour toutes les baies enregistrées, puis contourner l’autorisation pour obtenir un contrôle administratif complet de l’infrastructure de stockage.

La seconde, CVE-2026-63692, se situe dans le proxy d’autorisation et le service de tenants. Elle permet là encore de contourner les contrôles d’authentification pour gagner les privilèges administrateur. Dell le formule sans détour : la faille « est considérée comme critique car elle permet à un attaquant non authentifié d’obtenir un contrôle administratif complet du service d’autorisation, ouvrant potentiellement un accès et une manipulation non autorisés des ressources de stockage sur tous les tenants ».

Quatre failles de plus : root, jetons forgés, Secrets

Le même jour, Dell a corrigé quatre autres failles critiques de CSM, toutes exploitables à distance sans privilège :

  • CVE-2026-67269 : obtention d’un root sur les nœuds du cluster ;
  • CVE-2026-54472 : accès administrateur au proxy CSM Authorization ;
  • CVE-2026-61421 : forge de jetons d’authentification pour s’octroyer des privilèges administrateur ;
  • CVE-2026-67273 : contournement des contrôles d’accès Kubernetes offrant une lecture de tous les Secrets à l’échelle du cluster.

L’ensemble dessine un scénario d’attaque cohérent. Un attaquant qui atteint le module d’autorisation peut, en enchaînant quelques-unes de ces failles, passer d’aucun accès à administrateur du stockage, puis à root sur les nœuds, avec au passage la lecture des Secrets — ces objets Kubernetes qui concentrent mots de passe, clés et jetons de l’ensemble des applications.

Ce que l’exploitation permet concrètement

La gravité ne tient pas seulement aux privilèges obtenus, mais à ce qu’ils représentent. Le contrôle administratif du stockage signifie lire, modifier ou détruire les volumes qui portent les données de production. Le root sur les nœuds signifie s’affranchir des limites du conteneur et se déplacer latéralement dans le cluster. La lecture des Secrets signifie récupérer d’un coup les identifiants de services, de bases de données et de comptes cloud.

Dell n’a pas encore signalé d’exploitation active de ces six failles, mais le précédent incite à la prudence. En février 2026, Mandiant et Google Threat Intelligence Group ont révélé que le groupe UNC6201, soupçonné de liens avec la Chine et proche de Silk Typhoon, exploitait depuis mi-2024 une faille à identifiants codés en dur (CVE-2026-22769) dans Dell RecoverPoint for Virtual Machines pour déployer des charges malveillantes sur des serveurs VMware ESXi. Quelques jours plus tard, la CISA ordonnait aux agences fédérales de patcher leurs systèmes Dell vulnérables sous trois jours.

La correction tient en une mise à jour

Dell demande de mettre à niveau les modules de stockage conteneurisés vers la version 1.18.0 ou supérieure, qui corrige l’ensemble des six failles. L’éditeur recommande « de mettre à niveau le plus tôt possible ».

La bonne nouvelle est que la correction est centralisée : les six vulnérabilités étant toutes dans CSM et ses modules associés, une seule montée de version les couvre. La mauvaise est que CSM n’est pas toujours dans le périmètre de veille des équipes Kubernetes : il est souvent déployé par l’équipe stockage, puis oublié. Une faille d’authentification ne se déclenche, en pratique, que si l’attaquant peut joindre le service — c’est le premier point à vérifier avant même la montée de version.

Un motif récurrent dans la couche stockage

Les absences d’authentification (CWE-306) sur des fonctions critiques ne sont pas une exception dans l’écosystème du stockage conteneurisé. La couche CSI et ses modules satellites parlent à la fois au stockage et au cluster, ce qui en fait une cible à fort rendement : une seule faille y vaut souvent plusieurs privilèges à la fois.

La conséquence opérationnelle est double. D’une part, ces composants sont rarement dans la cartographie des équipes Kubernetes, qui suivent les pods, les services et les ingress, mais pas les CRDs et les controllers que l’équipe stockage a déployés en amont. D’autre part, leur surface d’exposition est mal maîtrisée : le service CSM Authorization écoute souvent derrière un ClusterIP ou un LoadBalancer dont personne n’a vérifié qui peut l’atteindre.

Pour détecter une compromission de ce type, trois signaux comptent : une connexion non authentifiée au service d’autorisation, une création inattendue de comptes administrateur sur les baies, et une lecture anormale des Secrets — souvent trahie par des changements d’accès aux volumes ou des exports de configuration inhabituels. La mise à jour 1.18.0 referme les failles, mais sans ces signaux, rien ne dit qu’une exploitation passée n’a pas déjà eu lieu.

Le piège de l’absence d’authentification tient à sa discrétion. Une CWE-306 ne laisse aucune trace dans un diff : la fonction existe, elle s’exécute, et rien dans le code ne crie « il manque une vérification ». C’est une faille de conception, pas une erreur de code — elle échappe aux revues qui traquent les bogues, et se détecte surtout en auditant qui peut joindre quel endpoint, pas en relisant les lignes.

Verdict

Si vous exploitez Dell CSM en production, appliquez la mise à niveau vers 1.18.0 cette semaine, sans attendre un signal d’exploitation : six failles critiques qui se combinent en un chemin complet vers l’admin du stockage et le root du cluster ne justifient pas la patience. En attendant, coupez l’exposition du service CSM Authorization aux réseaux non maîtrisés. Et si vous ne savez pas si CSM est installé, c’est le vrai problème : listez vos déploiements CSI et leurs modules associés, car cette couche est devenue un pivot privilégié que trop d’équipes surveillent mal.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer