Trois vulnérabilités touchant containerd, le moteur d’exécution de conteneurs utilisé par Google Kubernetes Engine et par Amazon EKS, ont été confirmées et corrigées au cours des dernières semaines. Référencées CVE-2026-50195, CVE-2026-53488 et CVE-2026-53492, elles touchent le composant CRI (Container Runtime Interface) qui fait le lien entre Kubernetes et le moteur de conteneurs sur chaque nœud. Google a confirmé les trois failles dans son bulletin de sécurité GKE, et Amazon a publié de son côté une alerte fixant le score CVSS de la première à 8,8 sur 10. Le flux CVE officiel de Kubernetes, lui, était encore mis à jour le 29 septembre 2026, signe que le dossier reste actif.
Ce qui rend l’affaire intéressante pour les équipes cloud françaises et européennes, ce n’est pas tant la gravité brute des scores CVSS que le point d’entrée commun aux trois failles : la restauration de checkpoints et la gestion des métadonnées d’image. Un attaquant qui dispose du simple droit de créer un Pod, sans accès root ni accès au nœud lui-même, peut dans certains scénarios empoisonner le cache d’images d’un nœud, faire exécuter une commande sur l’hôte, ou détourner des périphériques matériels via les annotations CDI. Voici ce que l’on sait, ce que Google et containerd ont corrigé, et ce que cela change pour la sécurité des clusters Kubernetes gérés en 2026.
Les faits en bref : trois CVE, un point commun
Les trois vulnérabilités partagent une racine technique commune : le traitement des checkpoints containerd, un mécanisme qui permet de sauvegarder l’état d’un conteneur en cours d’exécution puis de le restaurer plus tard, potentiellement sur un autre nœud. C’est un mécanisme puissant, pensé pour la migration de charge et la reprise après incident, mais il manipule des métadonnées (références d’image, labels, annotations d’appareils) qui n’étaient pas suffisamment validées avant d’être réinjectées dans le moteur d’exécution.
Le bulletin de sécurité de Google Cloud pour Google Kubernetes Engine confirme que les trois CVE affectent containerd et ont été résolues par une mise à jour vers la version 2.1.9 du moteur, intégrée au changelog de GKE 1.34. Un quatrième identifiant, CVE-2026-46680, est mentionné dans ce même changelog comme corrigé par la même mise à jour, sans que les informations disponibles ne précisent sa nature exacte ni son composant. Le fil CVE public de Kubernetes, consulté à la date du 29 septembre 2026, continuait de recenser et de mettre à jour ces entrées, ce qui confirme que le dossier reste suivi de près par la communauté plus de trois mois après les premiers correctifs en amont.
Point important pour évaluer le risque réel : aucune des trois failles n’est exploitable par un utilisateur anonyme depuis Internet. Les trois exigent qu’un attaquant dispose déjà d’un droit de création de Pods dans le cluster, autrement dit un accès déjà partiellement légitime (compte de service compromis, charge de travail malveillante déployée par un développeur peu vigilant, ou locataire malveillant dans un environnement multi-tenant). C’est une nuance essentielle : ces CVE ne sont pas des portes d’entrée directes, ce sont des failles d’escalade et de contournement d’isolation une fois à l’intérieur du cluster.
CVE-2026-50195 : le cache d’images empoisonné
La première faille, et la seule pour laquelle un score CVSS précis a été publié (8,8, selon le bulletin de sécurité d’Amazon Web Services référencé sur la base NVD), touche le processus d’import de checkpoint dans le plugin CRI de containerd. Le moteur ne valide pas correctement les références d’image contenues dans la configuration d’un checkpoint importé. Concrètement, un attaquant capable de créer des Pods peut forger un checkpoint qui force containerd à tirer une image qu’il contrôle, puis à l’enregistrer localement sous un tag arbitraire.
La conséquence est ce que les chercheurs appellent un empoisonnement du cache d’images local du nœud. Si un autre Pod légitime référence la même image avec une politique de tirage IfNotPresent ou Never, il risque d’exécuter la version piégée conservée en cache, sans le savoir. Le résultat final est une exécution de code croisée entre Pods partageant le même nœud, sous l’identité de la victime, un scénario particulièrement problématique dans les clusters multi-équipes où plusieurs applications tournent côte à côte pour des raisons de coût.
CVE-2026-53488 : des labels d’image qui exécutent des commandes
La deuxième faille s’attaque à un mécanisme plus discret : la propagation des labels d’image, ces métadonnées définies via l’instruction LABEL d’un Dockerfile, vers le conteneur en cours de création. Le plugin CRI de containerd ne valide pas suffisamment ces labels avant de les transmettre à d’autres composants ou opérations internes qui les consomment.
Un attaquant peut injecter des labels appartenant à des espaces de noms réservés, notamment containerd.io/ et io.cri-containerd, à l’intérieur d’une image malveillante. Selon la description retenue par Google dans son bulletin GKE, cela peut conduire à une exécution de commande arbitraire sur l’hôte, un scénario qui dépasse largement le simple conteneur pour toucher directement le système d’exploitation du nœud. Aucun score CVSS public précis n’a pu être retrouvé pour cette entrée au moment de la rédaction, ce qui n’enlève rien à la gravité de l’impact décrit : il s’agit potentiellement d’une échappatoire de conteneur classique, conditionnée à la présence du plugin ou de l’opération vulnérable sur le nœud concerné.
CVE-2026-53492 : les annotations CDI détournées
La troisième CVE cible un mécanisme plus récent et plus spécialisé : le Container Device Interface (CDI), qui permet à Kubernetes d’attribuer des périphériques matériels spécifiques, GPU compris, à des conteneurs de façon standardisée. Lors de la restauration d’un checkpoint, containerd fait confiance aux annotations CDI contenues dans des métadonnées non fiables, sans les revalider.
Un attaquant disposant du droit de créer des Pods peut ainsi contourner les mécanismes normaux d’allocation de ressources et de contrôle des device-plugins de Kubernetes, en injectant des modifications CDI arbitraires : nœuds de périphériques, montages de systèmes de fichiers de l’hôte, ou autres configurations matérielles. Le résultat peut être un accès non autorisé à du matériel de l’hôte ou une escalade de privilèges à l’intérieur du conteneur restauré. La base NVD précise toutefois une condition d’exploitation stricte : le CDI doit être activé sur le nœud, et une spécification CDI correspondante côté hôte doit exister pour le périphérique demandé. Les nœuds sans CDI activé, ou sans spécification sensible correspondante, ne sont pas concernés par ce vecteur précis.
Versions affectées et correctifs disponibles
Les correctifs en amont ont été publiés par le projet containerd, sous gouvernance de la CNCF, dans plusieurs branches actives à la fois. Le tableau ci-dessous résume les versions concernées et les versions corrigées pour chacune des trois failles.
| CVE | CVSS connu | Composant touché | Versions affectées | Versions corrigées |
|---|---|---|---|---|
| CVE-2026-50195 | 8,8 (bulletin AWS) | Import de checkpoint / cache d’images | < 2.3.2, < 2.2.5, < 2.1.9 | 2.3.2, 2.2.5, 2.1.9 |
| CVE-2026-53488 | Non publié dans les sources consultées | Labels d’image / plugin CRI | 1.7.x < 1.7.33, 2.0.x < 2.0.10, 2.1.x < 2.1.9, 2.2.x < 2.2.5, 2.3.x < 2.3.2 | 1.7.33, 2.0.10, 2.1.9, 2.2.5, 2.3.2 |
| CVE-2026-53492 | Non publié dans les sources consultées | Annotations CDI / restauration checkpoint | < 2.3.2, < 2.2.5, < 2.1.9 | 2.3.2, 2.2.5, 2.1.9 |
Des distributions dérivées ont publié leurs propres builds patchés avec un calendrier parfois décalé. C’est le cas de Volcengine, qui a listé dans son avis des versions spécifiques à sa plateforme VKE, à ne pas confondre avec la numérotation amont de containerd. Pour toute équipe qui gère elle-même ses nœuds Kubernetes en dehors des offres managées, la vérification de la version exacte de containerd installée reste la première étape incontournable.
La réponse de Google et un calendrier de correctifs à deux vitesses
Sur Google Kubernetes Engine, le déploiement des correctifs n’a pas suivi un calendrier uniforme selon le système d’exploitation du nœud. Les images Container-Optimized OS patchées ont été ajoutées pour les versions mineures de Kubernetes 1.35 et 1.36 le 20 juin 2026, et pour les versions 1.30 à 1.34 la veille, le 19 juin 2026. Les images basées sur Ubuntu, elles, étaient toujours en cours de développement au moment où le bulletin correspondant a été mis à jour par Google, sans date de disponibilité précisée dans les sources consultées.
Ce décalage illustre une réalité peu discutée des clusters Kubernetes managés : deux clients du même service, sur la même version de Kubernetes, peuvent se retrouver exposés à des fenêtres de risque différentes selon leur choix d’image de nœud. Google indique par ailleurs n’avoir imposé aucune action manuelle aux clients une fois le correctif déployé côté plateforme, les mises à jour d’image de nœud gérées automatiquement suffisant à absorber le correctif pour les clusters en auto-upgrade.
Un impact qui dépasse Google Cloud
Le fait qu’Amazon ait publié son propre bulletin de sécurité pour CVE-2026-50195, avec un score CVSS de 8,8, confirme que le problème ne se limite pas à GKE. Containerd est le moteur d’exécution par défaut d’Amazon EKS depuis plusieurs versions, tout comme il équipe de nombreuses distributions Kubernetes auto-gérées via containerd ou via l’intermédiaire de Docker Engine, qui s’appuie lui-même sur containerd en interne. Toute organisation qui exploite des clusters Kubernetes, qu’ils soient chez Google, chez Amazon, ou sur des nœuds on-premise construits avec containerd, doit vérifier son exposition, indépendamment du fournisseur cloud choisi.
Comment vérifier l’exposition de son cluster
La première étape consiste à identifier la version de containerd réellement déployée sur chaque nœud, plutôt que de se fier uniquement à la version de Kubernetes affichée dans la console. Les commandes suivantes permettent un premier diagnostic rapide sur un nœud Linux exécutant containerd.
# Vérifier la version de containerd installée sur le nœud
ctr version
# Lister les images en cache localement, à la recherche d'images inattendues
ctr -n k8s.io images list
# Vérifier si le CDI est activé (dossier de spécifications non vide)
ls -la /etc/cdi/ /var/run/cdi/ 2>/dev/null
# Sur un cluster GKE, vérifier la version d'image de nœud active
gcloud container node-pools describe NODE_POOL_NAME \
--cluster CLUSTER_NAME --zone ZONE \
--format="value(config.imageType,version)"Si la version de containerd est antérieure à 1.7.33, 2.0.10, 2.1.9, 2.2.5 ou 2.3.2 selon la branche utilisée, le nœud reste exposé à au moins une des trois failles. Sur GKE, la mise à jour automatique des nœuds (node auto-upgrade) résout le problème sans intervention si elle est activée ; dans le cas contraire, une mise à jour manuelle du pool de nœuds s’impose.
Réduire la surface d’attaque en attendant le correctif
Comme les trois vulnérabilités exigent qu’un attaquant dispose déjà d’un droit de création de Pods, la première ligne de défense reste le contrôle d’accès. Restreindre les permissions RBAC de création de Pods aux seuls comptes de service qui en ont réellement besoin réduit mécaniquement le nombre d’acteurs capables de déclencher l’une de ces failles. L’admission controller Pod Security Standards de Kubernetes, en profil restricted, limite également certaines capacités qui facilitent l’exploitation post-compromission.
Pour CVE-2026-53492 spécifiquement, désactiver le Container Device Interface sur les nœuds qui n’en ont pas l’usage (c’est-à-dire la majorité des nœuds sans charge de travail GPU ou matériel spécialisé) supprime purement et simplement le vecteur d’attaque, puisque la faille exige que le CDI soit actif. Pour les deux autres CVE, l’application stricte de politiques d’admission qui interdisent l’usage du mécanisme de checkpoint/restore aux workloads non explicitement autorisés limite l’exposition en attendant une mise à jour complète du parc de nœuds.
Contexte : une année 2026 chargée pour la sécurité des conteneurs cloud natifs
Ces trois CVE containerd ne sortent pas de nulle part. L’année 2026 a été marquée par une série de découvertes touchant la couche d’isolation des environnements conteneurisés hébergés par les grands fournisseurs cloud, un thème récurrent que ce site a déjà documenté à plusieurs reprises. Quelques semaines avant la divulgation de ce lot de failles containerd, Cloudflare avait dû corriger une fuite de données inter-locataires touchant sa plateforme Cloudflare Containers, où des blocs de disque résiduels d’un client pouvaient être récupérés par un autre client partageant le même serveur physique.
Plus tôt dans l’année, une autre vulnérabilité avait déjà touché la couche runtime des clusters GKE, sous le nom de code Fragnesia, avec un délai de correction jugé long par la communauté de sécurité. Kyverno, l’outil de gestion de politiques largement utilisé dans les clusters Kubernetes en production, a lui aussi fait l’objet de six CVE distinctes en 2026, renforçant l’idée que la chaîne d’outils qui entoure Kubernetes, et pas seulement Kubernetes lui-même, concentre une part croissante du risque.
Un motif technique qui se répète : la confiance excessive dans les métadonnées
Le fil conducteur des trois CVE containerd de cette vague est la confiance insuffisamment vérifiée accordée à des métadonnées contrôlées par l’attaquant à la frontière du CRI : références d’image dans un checkpoint, labels d’image, annotations CDI. Dans les trois cas, un utilisateur disposant du droit de créer des Pods peut atteindre un chemin de code sensible du runtime. C’est un motif que l’on retrouve régulièrement dans les architectures cloud natives modernes, où la frontière entre configuration déclarative et exécution privilégiée s’est considérablement complexifiée depuis l’introduction de fonctionnalités comme le checkpoint/restore ou le CDI, toutes deux relativement récentes dans l’écosystème containerd.
Containerd face à CRI-O et Docker : une comparaison à nuancer
Containerd, CRI-O et Docker Engine restent les trois moteurs d’exécution de conteneurs les plus utilisés dans l’écosystème Kubernetes. Containerd, projet gradué de la CNCF au même titre que Kubernetes lui-même, est le runtime par défaut de GKE, d’Amazon EKS et de la majorité des distributions Kubernetes managées récentes. CRI-O a été conçu spécifiquement pour Kubernetes, sans les couches historiques héritées de Docker, tandis que Docker Engine reste utilisé dans des contextes de développement local ou d’intégration continue, tout en s’appuyant lui-même sur containerd en interne depuis plusieurs années.
Les recherches menées pour cet article n’ont pas permis d’identifier un ensemble comparable de CVE publiées en 2026 pour CRI-O ou pour Docker Engine avec un niveau de détail équivalent à celui disponible pour containerd. Il serait donc trompeur d’en tirer une conclusion chiffrée sur la sécurité relative des trois runtimes : l’absence de CVE documentée dans les sources consultées ne signifie ni une absence de vulnérabilités, ni une supériorité de sécurité, simplement une différence de visibilité publique au moment de la rédaction. Ce qui est vérifiable, en revanche, c’est que la surface d’attaque du CRI, commune aux trois runtimes dans leur intégration Kubernetes, reste le point de convergence naturel de ce type de recherche de vulnérabilités.
Conditions d’exploitation : ce qu’il faut retenir pour évaluer le risque
Toutes les CVE de sécurité ne se valent pas, et le score CVSS seul ne suffit pas à prioriser une remédiation. Le tableau ci-dessous résume les conditions concrètes que doit réunir un attaquant pour exploiter chacune des trois failles, un élément clé pour les équipes qui doivent arbitrer entre correctif immédiat et correctif planifié.
| CVE | Permission requise | Condition supplémentaire | Résultat pour l’attaquant |
|---|---|---|---|
| CVE-2026-50195 | Créer des Pods | Une autre charge de travail victime doit utiliser IfNotPresent/Never | Exécution de code sous l’identité d’un autre Pod |
| CVE-2026-53488 | Déployer une image malveillante | Un plugin ou une opération doit consommer les labels d’image concernés | Exécution de commande arbitraire sur l’hôte |
| CVE-2026-53492 | Créer des Pods avec restauration de checkpoint | CDI activé sur le nœud, avec spécification hôte correspondante | Accès non autorisé à un périphérique ou aux montages de l’hôte |
Cette lecture par conditions d’exploitation montre que les clusters les plus exposés sont ceux qui autorisent un grand nombre d’équipes ou de projets externes à déployer librement des images non vérifiées, un scénario courant chez les fournisseurs de plateformes SaaS ou de CI/CD partagée qui exposent une forme de multi-tenant Kubernetes à leurs propres clients.
Impact sur le marché du cloud managé et la confiance des entreprises
Pour les entreprises françaises et européennes qui migrent des charges de travail critiques vers Kubernetes managé, ce type de vulnérabilité renforce un débat déjà présent dans les comités de sécurité : celui de la frontière de responsabilité entre le fournisseur cloud et le client dans le modèle de responsabilité partagée. Google, comme Amazon, gère et corrige le runtime sous-jacent, mais la configuration des permissions RBAC, l’activation ou non du CDI, et la politique de tirage d’images restent entièrement du ressort du client.
Le décalage observé entre les images Container-Optimized OS et les images Ubuntu sur GKE illustre également un point souvent sous-estimé dans les audits de conformité : le choix du système d’exploitation du nœud, une simple case à cocher lors de la création d’un pool de nœuds, peut se traduire par des semaines d’écart dans la disponibilité d’un correctif de sécurité critique. Pour les secteurs régulés, banque, assurance, santé, qui doivent documenter leurs délais de remédiation dans le cadre de la directive européenne NIS2 ou du futur règlement sur la cyber-résilience, ce type de dépendance mérite d’être tracé explicitement dans les registres de risque.
Ce que cela révèle sur la maturité de la sécurité du CRI
Le Container Runtime Interface a été conçu à l’origine pour standardiser la communication entre Kubernetes et n’importe quel moteur de conteneurs, un objectif largement atteint sur le plan de l’interopérabilité. Mais cette standardisation a aussi concentré, dans une interface commune, des fonctionnalités de plus en plus puissantes, checkpoint/restore, CDI, gestion fine des labels, sans que la validation des métadonnées associées progresse au même rythme. Les trois CVE de cette vague pointent toutes vers le même constat : les nouvelles fonctionnalités du CRI introduites ces dernières années ont élargi la surface d’attaque plus vite qu’elles n’ont été auditées.
C’est un constat que la CNCF elle-même reconnaît implicitement à travers la montée en puissance de ses programmes d’audit de sécurité financés pour les projets graduués, dont containerd fait partie depuis plusieurs années. La rapidité de publication des cinq versions correctives en amont (1.7.33, 2.0.10, 2.1.9, 2.2.5, 2.3.2, couvrant simultanément cinq branches actives) montre en tout cas une réactivité de mainteneur qui contraste avec le calendrier plus étalé observé côté distribution des images de nœud chez les fournisseurs cloud.
Prédictions : ce qui va probablement changer d’ici la fin de l’année
- D’autres CVE liées au CRI devraient émerger dans les prochains mois, à mesure que les chercheurs en sécurité, désormais familiers du motif checkpoint/métadonnées non validées, appliquent la même méthode à d’autres portions du code de containerd et de CRI-O.
- Les fournisseurs cloud vont probablement resynchroniser leurs calendriers de correctifs entre familles d’images de nœud, l’écart observé entre Container-Optimized OS et Ubuntu sur GKE étant difficilement défendable pour des failles à fort impact.
- Le CDI devrait progressivement passer d’une activation par défaut à une activation explicite sur les nœuds qui n’en ont pas l’usage, une évolution de configuration déjà recommandée par plusieurs équipes de sécurité cloud natives.
- Les politiques RBAC de création de Pods vont probablement se durcir dans les environnements multi-tenant, en particulier chez les fournisseurs de plateformes qui exposent Kubernetes à des équipes externes ou à des clients tiers.
- La pression réglementaire européenne devrait s’accentuer sur la traçabilité des délais de correction des composants d’infrastructure cloud, dans le sillage des obligations de notification introduites par la directive NIS2 pour les opérateurs de services essentiels.
Que doivent faire les équipes DevOps et SRE dès maintenant
Au-delà de la mise à jour vers une version corrigée de containerd, les équipes qui opèrent des clusters Kubernetes en production, qu’ils soient managés ou auto-hébergés, ont intérêt à revoir trois points précis. D’abord, l’inventaire des identités qui disposent du droit de créer des Pods, souvent plus large que nécessaire dans les clusters qui ont grandi organiquement au fil des projets. Ensuite, l’audit de l’activation du CDI sur l’ensemble du parc de nœuds, une fonctionnalité fréquemment activée par défaut dans certaines images optimisées pour les charges de travail GPU, même quand elle n’est pas utilisée. Enfin, la vérification systématique, via les commandes présentées plus haut, de la version réelle de containerd déployée, indépendamment de ce qu’affiche la console du fournisseur cloud pour la version de Kubernetes.
Pour les organisations qui exploitent des clusters hybrides, mêlant GKE, Amazon EKS et infrastructure auto-gérée, la difficulté supplémentaire consiste à s’assurer que le suivi de version de containerd ne dépend pas uniquement des notifications du fournisseur cloud, mais s’appuie aussi sur une veille directe des avis de sécurité du projet containerd, disponibles publiquement sur son dépôt GitHub.
Foire aux questions
Ces failles containerd sont-elles exploitables depuis Internet, sans accès préalable au cluster ?
Non. Les trois CVE exigent qu’un attaquant dispose déjà du droit de créer des Pods dans le cluster Kubernetes ciblé. Ce ne sont pas des vulnérabilités exposées directement sur Internet, mais des failles d’escalade et de contournement d’isolation une fois un accès déjà obtenu.
Mon cluster GKE est-il automatiquement protégé ?
Si le node auto-upgrade est activé et que le pool de nœuds utilise une image Container-Optimized OS déjà patchée, oui. Si le pool utilise une image Ubuntu ou si les mises à jour automatiques sont désactivées, une vérification manuelle de la version de containerd s’impose.
Amazon EKS est-il aussi concerné ?
Oui pour CVE-2026-50195 : Amazon a publié son propre bulletin de sécurité confirmant un score CVSS de 8,8, puisque containerd est également le moteur d’exécution par défaut d’EKS. Les administrateurs EKS doivent vérifier la version de containerd de leurs groupes de nœuds de la même manière que sur GKE.
Faut-il désactiver le CDI sur tous mes nœuds ?
Seulement sur les nœuds qui n’ont pas de besoin identifié d’allocation fine de périphériques matériels (GPU, cartes réseau spécialisées). Sur les nœuds qui utilisent réellement le CDI, la mise à jour vers une version corrigée de containerd reste la réponse appropriée plutôt que la désactivation.
Quelle est la différence entre ces CVE et la faille Cloudflare Containers révélée en septembre 2026 ?
Il s’agit de deux problèmes distincts, sur des plateformes différentes. La faille Cloudflare touchait une fuite de blocs de disque résiduels entre locataires sur l’infrastructure edge de Cloudflare Containers. Les CVE containerd ici concernent le moteur d’exécution lui-même, utilisé par Google Kubernetes Engine et Amazon EKS, avec un mécanisme d’exploitation entièrement différent basé sur les métadonnées de checkpoint.
Existe-t-il un score CVSS officiel pour les trois CVE ?
Seule CVE-2026-50195 dispose d’un score CVSS publié et vérifiable, fixé à 8,8 par le bulletin de sécurité d’Amazon Web Services. Pour CVE-2026-53488 et CVE-2026-53492, aucun score CVSS n’apparaissait dans les sources consultées au moment de la rédaction, bien que leur impact décrit (exécution de commande sur l’hôte, accès non autorisé à des périphériques) soit potentiellement sévère selon le contexte de déploiement.
Docker Engine est-il vulnérable aux mêmes failles ?
Docker Engine s’appuie sur containerd en interne pour la gestion des conteneurs. Une installation Docker qui embarquerait une version vulnérable de containerd pourrait en théorie être affectée par des chemins de code similaires, mais les sources consultées pour cet article ne fournissent pas de confirmation officielle spécifique à Docker Engine pour ces trois CVE précises.
Où suivre les futures mises à jour de sécurité de containerd ?
Le dépôt GitHub officiel du projet containerd publie ses avis de sécurité (security advisories) directement, en complément des bulletins spécifiques à chaque fournisseur cloud comme celui de Google Cloud pour GKE.