Une vulnérabilité récemment révélée dans Red Hat OpenShift AI pourrait permettre à des utilisateurs peu privilégiés d’élever leurs privilèges et de prendre le contrôle complet de l’infrastructure cloud hybride.
La faille s’est vu attribuer un score CVSS de 9,9, proche du maximum, ce qui souligne sa gravité pour les organisations qui s’appuient sur OpenShift AI pour exécuter des charges de travail d’IA prédictive et générative.
« Un attaquant disposant de privilèges limités et ayant accès à un compte authentifié, comme un data scientist utilisant un notebook Jupyter, peut élever ses privilèges jusqu’à obtenir ceux d’un administrateur complet du cluster », a déclaré l’entreprise.
L’exploitation pourrait compromettre les charges de travail d’IA
OpenShift AI est largement adopté pour gérer le cycle de vie des modèles de machine learning dans les environnements cloud hybrides.
Les versions concernées — OpenShift AI 2.19 et 2.21, ainsi que les images de l’Operator Red Hat OpenShift AI — sont essentielles pour les organisations qui déploient des pipelines d’IA à grande échelle.
L’exploitation de cette vulnérabilité (CVE-2025-10725) pourrait permettre aux attaquants de dérober des données sensibles, de perturber les charges de travail et de compromettre l’infrastructure sous-jacente, mettant en péril les données sensibles et les opérations critiques.
Privilèges limités, prise de contrôle complète : au cœur de CVE-2025-10725
Au cœur de CVE-2025-10725 se trouve un ClusterRoleBinding mal configuré qui relie le kueue-batch-user-role au vaste groupe system:authenticated. Cette erreur de conception étend de fait les autorisations élevées à chaque utilisateur authentifié du cluster, au lieu de les limiter à des rôles précisément définis.
En pratique, la plupart des utilisateurs — comme les data scientists qui exécutent des expériences dans des notebooks Jupyter — ne devraient disposer que de droits limités pour soumettre ou gérer leurs propres charges de travail. Mais avec cette liaison en place, même des comptes peu privilégiés peuvent appeler l’API batch.kueue.openshift.io et créer arbitrairement des ressources Job ou Pod.
Une fois cette tête de pont établie, les attaquants peuvent enchaîner les élévations de privilèges en injectant des conteneurs ou des conteneurs d’initialisation malveillants. Ces charges de travail indésirables peuvent exécuter des commandes d’administration comme oc ou kubectl, usurper l’identité de comptes dotés de privilèges supérieurs et progresser étape par étape jusqu’à atteindre le rôle cluster-admin.
Avec les privilèges cluster-admin, l’attaquant dispose d’un contrôle sans restriction et peut effectuer les opérations suivantes :
- Exfiltrer des données : Accéder aux secrets, aux jeux de données et à la propriété intellectuelle stockés dans le cluster, et les dérober.
- Perturber les services : Supprimer des Pods, arrêter des tâches ou déployer des services qui dégradent les opérations ou les rendent indisponibles.
- S’emparer de l’infrastructure : Modifier la configuration du cluster, installer des portes dérobées persistantes ou rebondir vers d’autres ressources cloud.
Bien que l’exploitation nécessite un compte authentifié, la barrière reste relativement faible. De fait, un seul compte compromis ou détenu par un initié pourrait entraîner une compromission totale de la confidentialité, de l’intégrité et de la disponibilité. En pratique, cette mauvaise configuration transforme la conception mutualisée et multi-utilisateur de la plateforme en sa principale vulnérabilité, exposant des pipelines d’IA hybrides entiers à une prise de contrôle.
Briser la chaîne d’attaque dès le départ
Red Hat a publié des correctifs pour remédier à cette faille. Toutefois, l’application des correctifs pourrait ne pas suffire.
Pour réduire le risque d’élévation de privilèges et de prise de contrôle complète du cluster, les organisations doivent renforcer les contrôles d’accès et surveiller en permanence les signes d’abus. Les principales mesures d’atténuation sont les suivantes :
- Renforcer les contrôles RBAC : Supprimer le ClusterRoleBinding problématique, accorder les droits de création de tâches uniquement aux groupes de confiance et auditer les attributions de rôles afin d’appliquer le principe du moindre privilège.
- Surveiller les activités anormales : Suivre les créations inhabituelles de Pods, les élévations de privilèges des comptes de service et les appels d’API suspects vers batch.kueue.openshift.io.
- Utiliser des outils d’application des politiques : Déployer des contrôleurs d’admission ou des règles OPA/Kyverno pour bloquer les Pods non approuvés et empêcher les abus de privilèges.
- Segmenter et sécuriser les charges de travail : Isoler les espaces de noms, restreindre les chemins réseau et renouveler ou limiter les jetons des comptes de service afin de limiter les déplacements latéraux.
- Auditer et tester en continu : Effectuer des analyses de la posture de sécurité du cluster, conserver les journaux d’audit et organiser des exercices sur table de réponse aux incidents pour les environnements Kubernetes/OpenShift.
Bien que ces mesures réduisent le risque immédiat, cette révélation met en évidence des difficultés plus profondes pour sécuriser les environnements cloud hybrides pilotés par l’IA.
Pourquoi les services d’IA sont des cibles privilégiées des cyberattaques
Cette révélation souligne un défi croissant pour les entreprises : les services d’IA deviennent des cibles à forte valeur en raison de leur rôle central dans les pipelines de données, la protection de la propriété intellectuelle et les systèmes décisionnels critiques.
La faille d’OpenShift AI montre comment une simple erreur de configuration de la gestion des identités et des accès peut se transformer en compromission de toute une plateforme.
À mesure que les organisations étendent leurs déploiements cloud hybrides et adoptent des services de GenAI, le renforcement du RBAC et la rigueur en matière de correctifs doivent être traités avec la même urgence que l’application des correctifs aux systèmes d’exploitation et aux applications traditionnels. Les attaquants exploitent de plus en plus les plateformes cloud natives non pas au moyen de zero-days sophistiqués, mais en tirant parti de paramètres par défaut trop permissifs et de liaisons de privilèges négligées.
Lorsqu’une seule erreur de configuration peut faire tomber tout un cluster, le Zero Trust devient moins une stratégie qu’une nécessité.