Cette faille critique dans Kubernetes, révélée en janvier 2026, exploite la permission RBAC nodes/proxy GET pour exécuter du code à distance dans n’importe quel Pod du cluster, sans laisser de trace dans les logs d’audit. Cette vulnérabilité repose sur un contournement des vérifications d’autorisation : le Kubelet, via une connexion WebSocket, autorise l’exécution de commandes (/exec) en validant uniquement un GET initial, sans exiger le verbe CREATE normalement requis. L’absence de logs d’audit côté Kubelet aggrave le risque, permettant des attaques discrètes, notamment sur des composants système comme etcd ou kube-apiserver.
L’article souligne que des ServiceAccounts aux noms évocateurs, comme rook-ceph-system, combinés à des permissions étendues (accès en lecture aux Secrets), constituent des cibles privilégiées pour une élévation de privilèges. Une analyse des Roles et ClusterRoles est recommandée, avec des outils comme le script de détection du chercheur Graham Helton. Parmi les composants vulnérables figurent des outils courants comme l’OpenTelemetry Collector, dont les ServiceAccounts associés pourraient être exploités pour compromettre l’ensemble du cluster.
Pour atténuer ce risque, l’auteur propose plusieurs correctifs et mesures préventives, comme l’activation de la feature gate KEP-2862 pour un contrôle granulaire des autorisations Kubelet, l’utilisation de CiliumNetworkPolicy pour bloquer l’accès au port 10250, ou encore l’application de politiques Kyverno pour interdire la création de Roles incluant nodes/proxy. La surveillance des audit logs et la mise à jour des composants (comme Rook-Ceph) sont également essentielles, bien que Kubernetes ait classé cette faille comme un "comportement intentionnel" non corrigé en l’état.
