Notre vulnérabilité démarre débutnovembre 2025 quand Graham Helton, chercheur en sécurité, communique à l'équipe sécurité de Kubernetes une vulnérabilité dans les autorisations dans la gestion des rôles, le RBAC. Cette faille permet de contourner la sécurité RBAC et de pouvoir exécuter un code distant non autorisé : "un contournement autorisé dans RBAC de Kubernetes des permissions nodes/proxy GET permet d'exécuter des commandes sur tous les pods d'un cluster" introduit Graham. Le problème ne vient pas réellement de Kubernetes mais de l'interaction avec certains protocoles réseaux. 

Graham prévient Kubernetes puis plus rien jusqu'au mi-janvier. La réponse de l'époque sécurité de Kubernetes, publiée par Graham, confirme qu'il n'y aura de correction officielle, du moins, pas pour le moment : "Après un examen plus approfondi, nous confirmons notre décision selon laquelle ce comportement est conforme aux attentes et ne fera donc pas l'objet d'un CVE." explique l'équipe sécurité. Bien entendu, notre chercheur n'est pas d'accord.

"Nous sommes d'accord que nodes/proxy présente un risque, un patch pour restreindre ce chemin spécifique serait nécessaire pour changer les autorisations dans kubelet et the kube-apiserver pour forcer une double autorisation de get et create. Nous avons déterminé que la mise en œuvre et la coordination d'une telle logique de double autorisation sont fragiles, architecturalement incorrectes et potentiellement incomplètes." explique la réponse de Kubernetes.

La suite est intéressante : "Nous restons convaincus que la proposition KEP-2862 constitue la solution architecturale appropriée. Plutôt que de modifier l'autorisation globale des nodes-proxy, notre objectif est de la rendre obsolète pour les agents de surveillance en déployant progressivement des permissions plus fines dans la version 1.6, prévue pour mars 2026." poursuit Kubernets. La méthode actuelle ne sera pas déprécier avant plusieurs après l'introduction de la nouvelle méthode, le temps d'évaluer les risques de casses de compatibilité et donc une casse de production si la méthode actuelle nodes/proxy était spécifiquement modifiée (sous-entendu pour combler la faille). 

Bref, oui la vulnérabilité existe, l'équipe sécurité ne le consteste pas mais elle explique que le comportement est conforme à ce qui est attendue et qu'aucune demande CVE ne sera faite et qu'il faut attendre une mise à jour d'architecture prévue au printemps 2026. L'autre point mis en avant est que toute correction spécifique sur la partie nodes/proxy pourrait casser la compatibilité avec les clusters actuels. L'équipe Kubernetes met en avant les changements qui seront faits dans la mise à jour d'avril 2026 en intégrant la spécifications KEP-2826. Graham, dans son dernier post, explique pourquoi la KEP-2862 ne fixe pas la faille. 

Seule solution : vérifier toutes les autorisation, restreinte les accès, monitorer tous les noeuds. 

Chronologie

1er novembre 2025 : rapport initial envoyé à l'équipe sécurité de Kubernetes. Puis traitement du dossier

14 décembre : l'équipe est informée du délai de non divulgation de 90 jours

7 janvier 2026 : mise à jour et relance de la requête

23 janvier : l'équipe sécurité dit qu'il n'y aura de correction de la vulnérabilité

26 janvier : Graham publie la vulnérabilité et le PoC d'exploitation

Publication complète de la vulnérabilité : https://grahamhelton.com/blog/nodes-proxy-rce