Le cloud repose sur une promesse que personne n’écrit en gros sur la facture : plusieurs clients peuvent partager la même infrastructure, à condition que chacun reste strictement enfermé dans son espace.
Avant la faille : Cloudflare, ça sert à quoi ?
Cloudflare est l’un des grands réseaux qui se placent entre les internautes et les applications qu’ils utilisent. Pour une entreprise ou un développeur, il peut accélérer un site grâce à son CDN, gérer le DNS d’un domaine, filtrer des attaques DDoS et du trafic malveillant avec un pare-feu applicatif, répartir le trafic, sécuriser les accès avec des services Zero Trust et rapprocher les contenus des utilisateurs grâce à son réseau mondial.
Cloudflare n’est toutefois plus seulement le bouclier placé devant un serveur. Avec sa Developer Platform, l’entreprise permet aussi d’exécuter du code avec Workers, de stocker des données et, désormais, d’exécuter des workloads conteneurisés sans gérer soi-même les machines physiques qui les hébergent.
C’est précisément pour cela que cette histoire compte. Lorsqu’une plateforme protège, accélère et parfois exécute directement une partie de nos applications, une faille dans la séparation entre deux clients ne touche plus un détail technique caché : elle touche la confiance sur laquelle repose le service.
Le 24 septembre 2026, Cloudflare a expliqué avoir corrigé une vulnérabilité dans Containers et Sandboxes qui rompait, dans certaines circonstances, cette frontière. Un client disposant d’un compte Workers Paid pouvait récupérer des fragments de données laissés sur des blocs de disque précédemment utilisés par d’autres conteneurs exécutés sur le même hôte.
Cloudflare affirme avoir entièrement corrigé le problème et n’avoir trouvé aucune preuve d’exploitation malveillante dans les traces historiques disponibles. Aucune action n’est demandée aux clients.
L’incident mérite pourtant mieux qu’un « c’est patché, circulez ».
Parce que la vraie histoire n’est pas Cloudflare. C’est la manière dont une infrastructure moderne peut être correctement isolée à un niveau, puis laisser apparaître une fuite à un autre.
Le cloud ne partage pas votre application. Il partage l’infrastructure. Toute la sécurité tient dans ce qui sépare les deux.
Une microVM par workload ne suffit pas si le disque oublie mal
Cloudflare Containers exécute les workloads dans des machines virtuelles légères basées sur Firecracker. Ce choix ajoute une frontière de virtualisation autour de chaque workload, alors qu’un conteneur classique partage davantage de composants avec son hôte.
Sur le papier, l’isolation est donc sérieuse.
Mais le problème découvert par Oren Yomtov et l’équipe de sécurité d’Accomplish se trouvait plus bas : dans la manière dont les blocs physiques de stockage étaient recyclés.
Cloudflare utilisait Linux device-mapper thin provisioning, ou dm-thin, pour fournir le disque racine inscriptible de chaque conteneur. Les volumes étaient découpés en blocs physiques de 64 KiB. Lorsqu’un volume était supprimé, ses blocs retournaient dans un pool partagé entre plusieurs workloads.
La configuration concernée utilisait l’option skip_block_zeroing.
Autrement dit, lorsqu’un bloc ancien était réattribué à un nouveau conteneur, le système n’effaçait pas nécessairement tout son contenu avant de le rendre disponible.
Si le nouveau workload écrivait seulement 4 KiB dans un bloc de 64 KiB, les 60 KiB restants pouvaient encore contenir des données provenant de l’utilisation précédente.
La faille ne consistait donc pas à « entrer » dans la machine virtuelle d’un autre client. Elle exploitait quelque chose de plus discret : de la mémoire de stockage qui n’avait pas été correctement neutralisée avant réutilisation.
Le détail qui transforme un bug de stockage en faille cross-tenant
Lire directement une zone encore non allouée ne suffisait pas. dm-thin renvoyait alors des zéros.
Les chercheurs ont contourné ce comportement en provoquant l’allocation d’un bloc physique avec une petite écriture de 4 KiB, puis en lisant le bloc entier.
Cette séquence pouvait faire apparaître les octets résiduels qui n’avaient pas été remplacés.
Lors de leurs tests, les chercheurs ont observé des traces étrangères sur 18 des 24 placements testés et sur 20 des 22 nœuds sous-jacents rencontrés. Ils ont notamment identifié des structures de répertoires, des pages de bases de données et des bases SQLite structurellement complètes.
Cela ne signifie pas que 18 clients sur 24 ont été compromis. Les placements n’étaient pas des victimes ciblées, et l’attaque ne permettait pas de choisir un compte, un workload ou un hôte précis.
Mais la frontière de confidentialité entre tenants pouvait être franchie.
Et dans une plateforme multi-tenant, c’est exactement la frontière qu’on ne veut jamais voir devenir probabiliste.
Cloudflare a corrigé deux problèmes, pas un seul
La première mesure a été évidente : retirer skip_block_zeroing afin que les nouveaux blocs soient remis à zéro avant d’être exposés à un autre workload.
Mais ce correctif ne suffisait pas.
Des blocs déjà mappés pouvaient encore exister dans des disques de conteneurs en cours d’exécution ou dans des snapshots d’images mis en cache sur les hôtes. Cloudflare a donc drainé les hôtes, recréé les disques concernés et supprimé les caches antérieurs à la mitigation.
Le déploiement initial du correctif a été achevé le 7 septembre. Le nettoyage des snapshots et données antérieurs a été terminé le 19 septembre. Le billet technique public a été publié le 24 septembre.
Cette séquence est intéressante parce qu’elle montre la différence entre « empêcher de nouvelles expositions » et « éliminer les artefacts hérités de l’ancien comportement ».
En sécurité, corriger la cause sans nettoyer l’état existant peut laisser une porte fermée avec les anciennes clés encore posées sous le paillasson.
Firecracker n’est pas le coupable magique, et Docker n’est pas l’accusé automatique
Le réflexe serait de conclure que les conteneurs partagés sont dangereux ou que Firecracker a échoué.
Ce serait aller trop vite.
Firecracker est justement conçu pour apporter une frontière de virtualisation forte aux workloads multi-tenant. Cloudflare indique que chaque conteneur disposait bien de sa microVM dédiée.
La fuite provenait du stockage sous cette frontière.
C’est une nuance importante pour les architectes : une architecture sécurisée n’est pas un composant « sécurisé » posé au milieu du diagramme. C’est une chaîne.
CPU, mémoire, hyperviseur, réseau, stockage, caches, secrets, orchestration, logs, sauvegardes : il suffit qu’une seule couche recycle mal une ressource pour que l’isolation globale devienne plus faible que prévu.
La sécurité du système est celle de ses interfaces, pas celle de son logo le plus rassurant.
Pourquoi cela nous concerne même si nous n’utilisons pas Cloudflare Containers
Pour beaucoup de petites équipes africaines, le cloud managé est précisément ce qui permet de construire vite sans recruter immédiatement une équipe infrastructure complète.
C’est rationnel.
Le mauvais enseignement serait donc : « il faut tout auto-héberger ».
Une petite entreprise qui quitte une plateforme managée bien opérée pour administrer seule un hyperviseur, ses correctifs, ses sauvegardes et ses secrets ne gagne pas automatiquement en sécurité. Elle déplace simplement la responsabilité.
Le bon enseignement est différent : ne jamais confondre externalisation de l’infrastructure et disparition du risque.
Lorsque l’on utilise une plateforme multi-tenant, il faut savoir quelles données y transitent, lesquelles y sont persistées, quels secrets sont exposés au workload, comment les environnements sont séparés et ce que l’on ferait si une frontière fournisseur se révélait imparfaite.
Trois questions à poser avant le prochain « wrangler deploy »
La première concerne les données : le workload manipule-t-il des informations que l’on accepterait de voir exposées dans un incident cross-tenant, même très improbable ?
La deuxième concerne les secrets : une compromission du filesystem donnerait-elle accès à des identifiants capables d’ouvrir d’autres systèmes ?
La troisième concerne l’architecture : le fournisseur constitue-t-il une seule couche parmi plusieurs, ou une compromission de cette couche donnerait-elle immédiatement accès à tout le reste ?
Ces questions ne servent pas à ralentir les déploiements. Elles servent à empêcher qu’une optimisation de confort devienne un point de défaillance unique.
Ce que Cloudflare a bien fait — et ce que l’incident rappelle quand même
Le signalement a été reçu le 4 septembre. Cloudflare indique avoir ouvert un incident quelques heures plus tard, déployé la mitigation dans les jours suivants, fait confirmer par les chercheurs que leur preuve de concept ne fonctionnait plus, puis publié une analyse technique détaillée.
Cette transparence est utile, notamment parce qu’elle permet de comprendre précisément la mécanique de la faille au lieu de rester sur un bulletin marketing.
Mais une bonne réponse à incident n’annule pas l’enseignement architectural.
Nous construisons de plus en plus sur des couches que nous ne voyons pas. Serverless, containers managés, bases distribuées, agents IA, edge computing : la simplicité du tableau de bord masque volontairement une infrastructure complexe.
C’est le produit.
Et c’est aussi le risque.
Le cloud nous évite de gérer beaucoup de machines. Il ne nous dispense pas de comprendre où commencent et où s’arrêtent nos frontières de confiance.