Conteneurs Linux - Quand l'isolation ne tient plus29 septembre 2026 à 12h38 / PAR KORBEN ✨ / 4 MIN DE LECTURE /Catégories connexes Écouter cet article ~ 5 minCe qu’il faut retenir Résumé généré par IADepthfirst estime qu'il faut désormais partir du principe qu'un attaquant saura sortir d'un conteneur sans grande difficulté, car tous les conteneurs partagent le même noyau Linux de l'hôteAWS ne considère plus les conteneurs comme une barrière de sécurité selon un bulletin de novembre 2025, et ne s'en sert plus pour isoler ses clients entre euxLes CVE du noyau Linux explosent, passant de 249 en janvier à 1650 en août, notamment car l'IA permet même à un attaquant modeste de fabriquer un exploit dès qu'une faille est publiéeLa société de sécurité Depthfirst a publié un billet que j'ai trouvé intéressant dans lequel il explique en gros que les conteneurs (Docker et compagnie) ne sont plus une barrière de sécurité suffisamment solide. La thèse du papier de ◊ c'est qu'il faut désormais partir du principe qu'un attaquant (hacker ou malware) saura sortir d'un conteneur quand il le veut, sans grande difficulté.En effet, un conteneur comme ceux que font tourner Docker ou Kubernetes, donne à un programme l'impression d'avoir sa propre machine. Sauf qu'en réalité, il n'embarque pas de système d'exploitation.

Tous les conteneurs d'un serveur passent par le même noyau Linux qui est celui de l'hôte et dont le rôle est de gérer pour eux la mémoire, le processeur ainsi que le réseau.Toutefois, beaucoup d'organisateurs de CTF notamment s'y fient les yeux fermés et hébergent plusieurs épreuves sur le même serveur, chacune dans son conteneur, en comptant uniquement sur la sécurité de l'hôte. Mais c'est un faux sentiment de sécurité, j'en veux pour preuve ce bulletin de sécurité d'AWS daté de novembre 2025 où il est expliqué que l'entreprise ne considère plus les conteneurs comme une barrière de sécurité et ne s'en sert donc plus pour isoler ses clients les uns des autres.Ce qui a changé depuis quelques mois, vous le savez, c'est le prix d'entrée de la recherche de failles puisqu'avec les modèles d'IA de pointe, même un attaquant avec des moyens modestes peut fabriquer sans effort, dès la publication d'une faille, un exploit contre des machines qui ne sont pas encore corrigées, alors qu'avant ça demandait de sérieuses compétences.source : DepthfirstEt les chiffres publiés par Depthfirst montrent que tout ça s'accélère puisque 249 CVE ont été publiées pour le noyau Linux en janvier, et en août on en a eu 1 650 !!Depthfirst relève également que sur les 36 CVE divulguées via le kernelCTF de Google, 13 sont réalisables via des interfaces ordinaires comme celles qu'un conteneur reçoit par défaut (dont les sockets locaux). En fait, on en croise sans le savoir dès qu'on passe systemd, Docker ou une base de données locale.Le 24 juillet dernier, Depthfirst a même décroché une place au kernelCTF avec un exploit 0day (donc avant tout correctif) et aujourd'hui, le PoC est en accès libre sur GitHub.

Rassurez-vous, côté noyau Linux, le correctif est sorti le 6 août mais malheureusement, côté Ubuntu la mise à jour au 24 septembre, affichait encore que le noyau de la 26.04 était en "Vulnerable, work in progress" et celui de la 24.04 en "Vulnerable". Bref, trouver des vulns ça va vite. Fixer ces vulns sur TOUTES les releases et les machines, ça prend du temps.

Alors qu'avait c'était l'inverse. Bref, tout a été chamboulé et c'est un peu la merde maintenant niveau cybersécurité pour patcher rapidement.Alors comment se protéger de tout ça ?Hé bien la solution de Depthfirst va vous mettre en PLS car eux proposent carrément de ne plus partager le noyau. Ils recommandent à la place de migrer les charges non fiables vers des microVM, autrement dit des machines virtuelles légères où chaque charge aura son propre noyau.

Le projet Firecracker en fait partie tout comme Kata Containers comme ça, en théorie, si un attaquant casse l'un de ces noyau, il ne compromet que sa propre instance et pas l'hôte dans son entièreté ni ses voisins.Reste que Firecracker s'appuie sur KVM, la brique de virtualisation du noyau Linux de l'hôte. Et comme vous le savez, KVM a eu ses propres failles. En effet, cet été, la faille Januscape ouvrait en grand la porte de la machine physique à un attaquant pourtant enfermé dans sa VM, à condition bien sûr que l'hôte autorise la virtualisation imbriquée (une VM dans la VM).

Alors certes, la surface d'attaque est plus petite mais loin d'être nulle.Voilà, en attendant, si vous êtes sous Ubuntu 24.04 ou 26.04, surveillez bien la mise à dispo du prochain noyau. Canonical a d'ailleurs annoncé il y a peu, une publication hebdomadaire des noyaux pour tenter de compenser cet emballement.Source : le billet de recherche de depthfirst Ajouter Korben à messources préféréesRéférenceshttps://aws.amazon.com/security/security-bulletins/rss/aws-2025-024/https://depthfirst.com/research/containers-are-no-longer-safePAR Korben ✨Korben.info reste gratuit grâce à ses lecteursPas de paywall ni de publicité programmatique. Si le site vous est utile et que vous voulez qu'il reste libre et indépendant, vous pouvez le soutenir sur Patreon.Soutenir le site Que faire après le bac quand on est passionné de cybersécurité ?Contenu partenaireEntièrement dédiée à la cybersécurité, l'école Guardia est accessible soit directement après le bac (post-bac), soit après un bac+2 ou bac+3.

En rejoignant l'école Guardia, vous deviendrez développeur informatique option cybersécurité (Bac+3) ou expert en cybersécurité (Bac+5).Guardia CS forme aussi les professionnels à la cybersécurité via plusieurs formations en ligneVoir le site internet de l'école de cybersécurité Guardia CS