CVE-2026-19444 : kubectl cp sous Windows écrit hors du dossier cible

Si tu administres des clusters Kubernetes depuis un poste Windows, une ligne dans le changelog du 28 septembre a de bonnes chances de te concerner directement : kubectl cp peut écrire des fichiers en dehors du dossier que tu lui as donné comme destination. Pas besoin d’un cluster mal configuré ni d’un bug exotique côté serveur — juste un conteneur dont tu n’es pas totalement sûr, et un client kubectl pas encore à jour.

Ce que dit l’avis de sécurité

La faille porte la référence CVE-2026-19444, un CVSS v3.1 de 6.5 (vecteur AV:A/AC:L/PR:H/UI:R/S:C/C:L/I:H/A:N) selon le Kubernetes Security Response Committee. Elle a été signalée par la chercheuse Moriel Harush et corrigée avec Marly Salazar, Maciej Szulik et Vyom Yadav, suivie sous le ticket #141294 et publiée dans l’annonce officielle de sécurité Kubernetes du 28 septembre 2026.

Un détail change tout dans ce dossier : seuls les clients kubectl tournant sous Windows sont touchés. Linux et macOS en sont indemnes, pas parce qu’ils ont été corrigés plus tôt, mais parce que le mécanisme d’extraction qui pose problème est spécifique à Windows.

Le mécanisme : un tar qui ne fait pas ce qu’on croit

kubectl cp ne lit pas directement les fichiers du conteneur. Il lance un tar à l’intérieur du conteneur pour construire une archive, qui est ensuite transférée puis dépaquetée sur ta machine. Tout le problème tient dans cette confiance implicite : si le binaire tar du conteneur est malveillant (ou simplement remplacé), il peut fabriquer une archive dont les chemins internes sortent du dossier de destination une fois extraite côté Windows. Résultat : une écriture de fichier arbitraire, limitée uniquement par les droits du compte Windows qui exécute la commande.

Ce n’est pas un problème côté API server, côté etcd, ni côté kubelet — rien à corriger sur ton cluster. La faille vit entièrement dans le binaire client que tu lances depuis ton poste ou ton agent CI.

Versions concernées et correctifs

Trois branches sont touchées, chacune avec sa version corrigée :

• 1.34.0 à 1.34.11 → corrigé en 1.34.12
• 1.35.0 à 1.35.8 → corrigé en 1.35.9
• 1.36.0 à 1.36.4 → corrigé en 1.36.5

La branche 1.37 n’apparaît pas dans la liste des versions affectées : elle est sortie après le correctif. Dans tous les cas, la bonne pratique reste de garder kubectl dans une version proche de celle du control plane — pas une raison de plus pour sauter trois versions mineures d’un coup.

kubectl version --client

Cette commande suffit à savoir si un poste ou un agent est exposé. Fais-la tourner sur chaque machine Windows qui touche à un cluster, pas seulement sur le poste que tu utilises au quotidien.

Qui est vraiment exposé

Sur le papier, un CVSS de 6.5 n’a rien d’alarmant — il faut une interaction utilisateur et des privilèges élevés côté attaquant pour que l’exploitation ait un sens. Dans la pratique, trois scénarios rendent ce correctif prioritaire plutôt qu’optionnel :

• Un cluster multi-tenant, où tu n’as pas un contrôle total sur le contenu de chaque pod que tu peux être amené à inspecter.
• Un agent CI Windows qui copie des artefacts depuis des conteneurs de build, potentiellement issus d’un repository externe ou d’une pull request non fiable.
• Une investigation incident response, où tu copies justement le contenu d’un pod compromis pour l’analyser — le pire moment pour découvrir que l’outil d’analyse lui-même peut être retourné contre toi.

Dans les trois cas, le point commun, c’est que tu utilises kubectl cp sur un contenu dont tu n’as pas la certitude qu’il est sain. C’est précisément la situation que cette faille cible.

Ce qu’il faut faire, dans l’ordre

1. Inventorie tous les binaires kubectl.exe en circulation — pas seulement les postes interactifs, mais aussi les images de développement, les runners CI et ce que déploient tes outils de gestion de parc.
2. Mets à jour vers la version corrigée de ta branche (1.34.12, 1.35.9 ou 1.36.5).
3. En attendant le déploiement, évite kubectl cp depuis des workloads multi-tenant, des jobs de build ou tout pod dont tu ne maîtrises pas le contenu.

Le correctif ne touche que le client. Aucune action côté serveur, aucun redémarrage de composant de contrôle, aucune fenêtre de maintenance à prévoir pour l’appliquer.

FAQ

Mes clusters Linux ou mes nœuds sont-ils affectés ?
Non. La faille touche uniquement l’extraction de l’archive côté client Windows. Le control plane, les nœuds et les clients kubectl Linux/macOS ne sont pas concernés.

Un CVSS de 6.5, est-ce que ça vaut vraiment la mise à jour en urgence ?
Le score reflète les conditions d’exploitation (droits élevés, interaction utilisateur requise), pas la gravité de l’impact une fois ces conditions réunies — une écriture de fichier arbitraire reste une primitive dangereuse, en particulier en contexte CI où le compte qui exécute kubectl a souvent plus de droits qu’un simple poste utilisateur.

Faut-il aussi vérifier les plugins kubectl tiers ?
L’avis ne couvre que le binaire officiel kubectl. Si tu utilises des wrappers ou des forks qui réimplémentent cp à partir du même mécanisme tar, vérifie-les séparément — rien ne garantit qu’ils héritent du correctif upstream.

En pratique

Ce genre de faille ne fait jamais la une, mais elle rappelle une chose simple : un client d’administration qui fait confiance par défaut au contenu qu’il manipule reste un point d’entrée, même quand le cluster lui-même est irréprochable. Si la sécurisation de tes clusters en général mérite une remise à plat, notre guide complet pour sécuriser un cluster Kubernetes couvre le sujet plus largement. Et si cette CVE t’intéresse pour sa mécanique côté Windows, elle complète bien celle qu’on a détaillée sur la faille zero-day Windows Shell CVE-2026-96951 — même système d’exploitation, deux surfaces d’attaque très différentes.

La prochaine étape est simple : lance l’inventaire de tes kubectl Windows cette semaine, pas au prochain audit de sécurité.