Quand un accès en lecture seule mène à une exécution de code à distance, voici une phrase qui résume bien la nouvelle vulnérabilité découverte dans Kubernetes. Ce problème de sécurité permet de contourner les autorisations du système de gestion des rôles (RBAC). Voici ce que l’on sait.

Le 1er novembre 2025, le chercheur en sécurité Graham Helton a remonté une vulnérabilité aux équipes de Kubernetes. Ce problème de sécurité se situe au niveau de la fonction RBAC (contrôle d’accès basé sur les rôles) de Kubernetes, et plus précisément au niveau de la permission⁣ (ce qui est donc une action de lecture). Elle est fréquemment accordée aux composants pour la surveillance et l’observabilité, notamment pour obtenir des métriques.

Le problème vient d’un défaut de logique dans la vérification des accès suite à l’initiation du WebSocket : le système autorise la connexion, car elle ressemble au départ à une simple demande de consultation, mais il oublie de vérifier les droits lorsque la commande est soumise par l’utilisateur. Cela signifie qu’il est envisageable d’exécuter des commandes sur n’importe quel Pod du cluster Kubernetes.

“Le Kubelet ne procède pas à une vérification d’autorisation après la mise à niveau de la demande de connexion et ne valide jamais si le compte de service dispose des autorisations nécessaires pour l’opération en cours d’exécution lorsque WebSockets est utilisé. Cela permet d’exécuter des commandes à l’aide du point de terminaison sans autorisations en utilisant un outil tel que websocat pour envoyer des demandes à l’aide de WebSockets.“, précise Graham Helton.

D’ailleurs, son rapport précise que 69 Helm charts sont concernés et peuvent représenter un point d’entrée permettant d’exploiter cette vulnérabilité. Il y a des noms bien connus comme Prometheus, Datadog, Grafana ou encore Trivy.

Kubernetes refuse de corriger la vulnérabilité

Le 23 janvier 2026, Graham Helton a reçu une réponse de la part de l’équipe de sécurité de Kubernetes. La réponse est surprenante : la vulnérabilité évoquée dans cet article n’a pas de référence CVE à ce jour, car l’équipe de Kubernetes considère qu’il s’agit d’un comportement attendu. Cela rejette donc la faute sur les charts.

“Après un examen approfondi avec SIG-Auth et SIG-Node, nous confirmons notre décision selon laquelle ce comportement fonctionne comme prévu et ne fera pas l’objet d’un CVE.“, précise un message adressé à Graham Helton par Kubernetes.

Enfin, un script de détection a été publié par le chercheur en sécurité pour vous aider à identifier vos services qui utilisent cette permission. En matière de protection, vous pouvez notamment limiter les accès sur l’API de Kubelet.

Je vous invite à lire cet article technique de Graham Helton pour en savoir plus.