Corriger Kubernetes passe aussi par le kubectl des postes Windows, pas seulement le plan de contrôle
Fin septembre 2026, le comité sécurité de Kubernetes corrige deux failles moyennes : CVE-2026-19444, un path traversal de kubectl cp sur Windows, et CVE-2026-2270, un confused deputy du contrôleur StatefulSet. La leçon vaut pour tous : mettre à jour le plan de contrôle ne protège ni votre poste d’administration, ni l’isolation entre namespaces.
23 septembre 2026. Le Kubernetes Security Response Committee corrige CVE-2026-2270, un confused deputy dans le contrôleur StatefulSet. 28 septembre 2026. Il publie CVE-2026-19444, un path traversal de kubectl cp qui n’affecte que Windows. 13 octobre 2026. La prochaine vague de patchs — 1.37.2, 1.36.6, 1.35.10 — est attendue, tandis que Kubernetes 1.34 atteint sa fin de vie le 27 octobre. Pourquoi c’est important : aucune de ces deux failles n’est spectaculaire au CVSS, mais ensemble elles révèlent que « patcher Kubernetes » couvre deux surfaces distinctes que beaucoup d’équipes confondent.
CVE-2026-19444 : le danger vit dans votre kubectl, pas dans l’API server
La première faille n’est pas dans le kube-apiserver. CVE-2026-19444 vit dans le client kubectl, et seulement dans sa version Windows. Le comité sécurité l’a documentée le 28 septembre 2026 : quand kubectl cp extrait des fichiers depuis un conteneur, il fait confiance aux chemins présents dans l’archive tar produite côté conteneur. Un binaire tar malveillant à l’intérieur du conteneur peut y glisser des séquences de traversée qui font atterrir les fichiers hors du dossier choisi par l’opérateur, partout où le compte Windows local a le droit d’écrire.
Le score reste modeste : CVSS 6.5, vecteur AV:A/AC:L/PR:H/UI:R/S:C/C:L/I:H/A:N. L’attaquant doit contrôler le contenu du conteneur et la victime doit lancer la commande — ce n’est pas une exploitation à distance en une requête. Mais ce profil est précisément celui des victimes réelles : les ingénieurs de support, les intervenants d’incident et les runners de CI/CD qui rapatrient des journaux, des crash dumps et des fichiers de configuration depuis des conteneurs tiers. Les clients Linux et macOS ne sont pas affectés ; ce sont les jump boxes Windows des environnements hybrides AKS et on-prem qui sont dans le collimateur.
Le correctif est dans kubectl 1.34.12, 1.35.9, 1.36.5 et 1.37.1, suivi en amont sous le numéro d’issue #141294. Et c’est là que le piège se referme : mettre à jour le plan de contrôle ne change rien à cette faille. Seul un client patché protège la machine Windows qui l’exécute.
Une histoire qui se répète depuis 2019
CVE-2026-19444 n’est pas une idée neuve : c’est la même idée qui revient. Kubernetes a déjà corrigé deux path traversal de kubectl cp, CVE-2019-11246 et CVE-2019-1002101, tous deux enracinés dans le même défaut de conception : kubectl cp construit une archive tar côté conteneur et l’extrait côté client, en faisant confiance aux chemins qu’elle contient.
Chaque correctif, depuis 2019, a colmaté un cas d’extraction précis plutôt que de refondre la commande. Les correctifs de 2019 traitaient les chemins Linux et macOS ; celui de 2026 comble un trou spécifique à Windows, dont la sémantique de chemins — lettres de lecteur, antislashs, noms de périphériques réservés — crée des possibilités de traversée qui n’existent pas sur les systèmes POSIX. Tant que le modèle de confiance de la commande n’aura pas changé — extraire du contenu influencé par l’attaquant sur une machine de confiance — kubectl cp restera une cible, à chaque nouveau format d’archive ou nouvelle plateforme cliente.
La leçon pour les équipes est pratique : traiter kubectl cp comme une opération à risque, surtout depuis des conteneurs tiers, et privilégier les alternatives quand c’est possible — journalisation côté serveur, export d’objets via l’API, ou volumes partagés — plutôt que de rapatrier des fichiers depuis un conteneur dont on ne maîtrise pas le contenu.
CVE-2026-2270 : un deputy trompé brise l’isolation entre namespaces
La seconde faille est plus intéressante sur le plan architectural. CVE-2026-2270 touche le kube-controller-manager, plus précisément le contrôleur StatefulSet, et correspond au motif du confused deputy : un composant à larges privilèges — le contrôleur — se fait abuser par un appelant à privilèges étroits — un utilisateur limité à son namespace — pour accomplir ce que cet appelant n’aurait jamais pu faire directement.
Le mécanisme est le suivant. Un utilisateur qui détient le droit d’écriture sur les objets StatefulSet et sur les objets ControllerRevision de son propre namespace peut manipuler une révision de sorte que, lorsque le contrôleur la réconcilie, le pod résultant soit créé dans un autre namespace, auquel l’attaquant n’a jamais eu accès. Le correctif restreint le contrôleur à ne restaurer que le champ spec du StatefulSet depuis une ControllerRevision, en retirant les métadonnées qui permettaient le saut inter-namespace.
Avec CVSS 5.9 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N), la faille paraît anodine. La complexité d’attaque élevée et les privilèges requis tirent le score vers le bas. Mais l’enjeu pratique pour une équipe qui exploite des clusters multitenants partagés, c’est l’isolation des namespaces elle-même : si un tenant disposant de permissions StatefulSet ordinaires peut placer un pod dans le namespace d’un autre, chaque hypothèse sur les frontières RBAC du cluster mérite une relecture. Le correctif est le même que pour le client : 1.34.12, 1.35.9, 1.36.5, 1.37.1, suivi sous l’issue #142097.
Le calendrier qui coince : 1.34 en fin de vie
Ces deux failles s’insèrent dans un calendrier de versions déjà serré. Kubernetes 1.34 est passé en mode maintenance le 27 août 2026 et atteint sa fin de vie le 27 octobre 2026. Après cette date, seuls les correctifs de sécurité critiques seront rétroportés, puis plus aucun.
Cela crée une fenêtre inconfortable pour toute équipe encore sur 1.34. Installer 1.34.12 ferme les deux CVE discutées ici, mais n’achète qu’un mois environ avant que la branche cesse de recevoir des correctifs. Les équipes qui traitent « patché » et « supporté » comme des synonymes vont avoir une mauvaise surprise fin octobre, quand la prochaine vulnérabilité atterrira sur une branche sans support. Et le coût de l’inaction n’est pas neutre : certains clouds facturent déjà un support étendu au-delà de la fin de vie pour leurs clusters 1.34.
La vague de patchs du 13 octobre 2026 — 1.37.2, 1.36.6 et 1.35.10 — apporte les correctifs sur les branches encore activement supportées, avec une date limite de cherry-pick fixée au 9 octobre.
Qui doit corriger quoi
La ligne de partage entre les deux failles est celle que les clients de Kubernetes managé oublient souvent. CVE-2026-2270 vit dans le kube-controller-manager, un composant du plan de contrôle. Sur Amazon EKS, Google GKE et Azure AKS, c’est le fournisseur qui opère ce plan de contrôle : c’est donc son calendrier de mise à jour qui détermine quand un cluster managé cesse d’être vulnérable. Le client doit tout de même vérifier que la version mineure de son cluster est à jour et que la mise à niveau automatique ou les fenêtres de maintenance sont bien activées — un plan de contrôle managé laissé sur une vieille version mineure ne se patche pas tout seul.
CVE-2026-19444, elle, vit dans le kubectl installé sur vos propres machines. Aucun fournisseur managé ne peut patcher votre client à votre place. Les postes d’administration Windows, les jump boxes et les agents de build CI/CD qui exécutent kubectl cp doivent être mis à jour indépendamment du cluster. C’est la partie du travail que personne d’autre ne fera pour vous.
Verdict
Si vous administrez des postes Windows qui exécutent kubectl, commencez par mettre à jour le client vers 1.34.12, 1.35.9, 1.36.5 ou 1.37.1 — c’est le seul correctif qui protège ces machines, et il n’arrivera jamais par une mise à jour du cluster. Si vous exploitez un cluster managé, confirmez que la version mineure du plan de contrôle est courante et que l’auto-upgrade est actif pour CVE-2026-2270, puis auditez vos hypothèses RBAC si des tenants partagent le cluster. Et si vous êtes encore sur 1.34, planifiez la migration avant le 27 octobre : rester sur une branche en fin de vie transforme la prochaine faille, même moyenne, en problème sans correctif.