Cloudflare a révélé le 24 septembre 2026 avoir corrigé une faille qui permettait à un client payant de lire des données laissées par d’autres clients sur son service Containers. L’entreprise californienne, qui héberge une partie croissante de l’infrastructure cloud européenne, assure n’avoir trouvé “aucune preuve” d’exploitation malveillante. Mais l’incident relance une question de fond pour tout le cloud multi-tenant : que se passe-t-il quand deux entreprises inconnues l’une de l’autre partagent le même disque physique ?
Le bulletin technique publié sur le blog de Cloudflare détaille un mécanisme précis, un chercheur externe rémunéré via un programme de bug bounty, et un correctif déployé en cinq jours. L’affaire touche directement Cloudflare Containers et Cloudflare Sandboxes, la brique sur laquelle l’entreprise fait tourner les agents de codage IA et les charges de travail conteneurisées de ses clients. Pour les équipes sécurité en France et en Europe qui migrent vers l’edge computing, le dossier mérite un décryptage complet : cause technique, chronologie, comparaison avec les concurrents, et ce que cela change pour les choix d’architecture cloud en 2026.
Ce que Cloudflare a découvert dans son infrastructure Containers
Le 4 septembre 2026, Oren Yomtov, chercheur en sécurité de la société Accomplish, signale à Cloudflare via son programme de bug bounty une faille touchant Cloudflare Containers et Cloudflare Sandboxes, ce second service étant lui-même construit sur Containers. Vingt jours plus tard, le 24 septembre, Cloudflare publie un billet de blog détaillé intitulé “How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers”, assumant publiquement l’incident plutôt que de le minimiser.
Le service Containers permet à des clients de faire tourner de vrais workloads Linux, avec leurs propres paquets et runtimes, sur l’infrastructure mondiale de Cloudflare. Le client ne choisit pas le serveur physique sur lequel son conteneur atterrit : Cloudflare place automatiquement chaque charge de travail sur un hôte disponible, selon une logique d’attribution dynamique classique du cloud multi-tenant. C’est justement cette mutualisation qui a ouvert la brèche.
Chaque conteneur reçoit son espace de stockage depuis un pool partagé de type dm-thin, une technologie de provisionnement fin (“thin provisioning”) du noyau Linux qui alloue l’espace disque à la demande plutôt qu’en réservant un volume fixe dès le départ. Le problème : ce pool avait été configuré avec l’option skip_block_zeroing activée. Concrètement, quand un conteneur libère un bloc de disque, ce bloc pouvait être réattribué à un autre conteneur sans être préalablement effacé. Un nouveau workload démarré sur le même hôte pouvait alors récupérer des résidus de données laissés par le locataire précédent, qu’il s’agisse de métadonnées de fichiers, de pages de bases de données ou de fragments applicatifs.
Il faut être précis sur la nature de l’incident. Ce n’est pas une évasion de conteneur (“container escape”) au sens classique, où un attaquant sort de son environnement isolé pour prendre le contrôle du serveur hôte. Aucune compromission de l’hôte n’a été démontrée. Les chercheurs, en utilisant un compte Workers Paid standard, ont pu prouver la fuite de données résiduelles, mais sans pouvoir cibler une victime précise, ni garantir que des données exploitables se trouveraient effectivement dans les blocs récupérés. Cloudflare qualifie l’exposition de “résiduelle” plutôt que d’active.
La chronologie complète, jour par jour
La rapidité de la réponse de Cloudflare mérite d’être détaillée, car elle tranche avec des délais de correction souvent mesurés en semaines voire en mois dans l’industrie du cloud. Le tableau ci-dessous reconstitue la séquence complète des événements telle que documentée dans le billet officiel de l’entreprise.
| Date | Événement |
|---|---|
| 4 septembre 2026 | Oren Yomtov (Accomplish) signale la faille via le programme de bug bounty de Cloudflare |
| Entre le 4 et le 19 septembre | Investigation interne, reproduction du scénario, préparation du correctif |
| 19 septembre 2026 | Remédiation complète déployée sur l’ensemble du parc (“fleet remediation”) |
| 19-24 septembre 2026 | Retrait de l’option skip_block_zeroing, recréation des disques existants et des snapshots en cache |
| 24 septembre 2026 | Publication publique du billet de blog détaillant l’incident |
| 25 septembre 2026 | Reprise de l’information par la presse spécialisée (Cyber Kendra, Cybersecurity News, The Hacker News) |
Quinze jours séparent le signalement du correctif complet, et cinq jours de plus avant la divulgation publique. Cloudflare a choisi la transparence totale sur le mécanisme technique, y compris le nom exact de l’option de configuration fautive, ce qui est rare pour un fournisseur cloud de cette taille. L’entreprise écrit noir sur blanc : “Cloudflare has fully remediated the vulnerability, and we have no evidence that customer data has been compromised.” Elle ajoute également : “In addition, we found no evidence of any malicious actor abusing this vulnerability”, et précise aux clients qu'”remediation does not require any further action by Cloudflare customers” (source officielle Cloudflare).
Pourquoi aucun CVE n’a été attribué
Contrairement à la plupart des failles couvertes habituellement dans nos colonnes, cet incident n’a reçu aucun identifiant CVE. La raison est structurelle : un CVE identifie généralement une vulnérabilité dans un logiciel versionné et distribué publiquement, comme une bibliothèque open source ou un système d’exploitation. Ici, le défaut résidait dans une configuration interne du pool de stockage dm-thin de Cloudflare, propre à son infrastructure propriétaire et non redistribuable. Ce cas de figure illustre une limite connue du système CVE : les vulnérabilités purement internes aux plateformes cloud échappent souvent à la nomenclature publique, ce qui complique le suivi pour les équipes de conformité qui s’appuient sur des bases comme la NVD pour prioriser leurs audits.
Une coïncidence troublante avec une faille Linux distincte
Au même moment, une autre vulnérabilité liée aux conteneurs a fait la une : CVE-2026-80521, une faille “use-after-free” dans le code du socket AF_UNIX du noyau Linux, pour laquelle un exploit public permet à un processus non privilégié de s’échapper d’un conteneur Docker ou Kubernetes et d’obtenir les droits root sur l’hôte. Il est important de ne pas confondre les deux dossiers : CVE-2026-80521 est une évasion de conteneur classique au niveau noyau, potentiellement plus grave dans son impact technique, tandis que l’incident Cloudflare est une fuite de données résiduelles au niveau du stockage, sans évasion démontrée. Les deux affaires partagent cependant un point commun : elles rappellent que l’isolation multi-tenant repose sur des couches empilées (noyau, système de fichiers, hyperviseur) et qu’une seule faiblesse dans l’une de ces couches suffit à fissurer l’ensemble.
Le contexte : un mois chargé pour la sécurité edge de Cloudflare
L’incident Containers ne survient pas isolément. Cloudflare a multiplié les annonces en septembre 2026, dessinant une entreprise qui pousse fort sur l’IA et l’edge compute, parfois plus vite que sa propre couche de sécurité ne peut absorber. Le 2 septembre, la société annonce le support des Cursor Cloud Agents sur Cloudflare Sandboxes, étendant son offre vers l’hébergement d’agents de codage autonomes, justement construits sur Containers. Le 3 septembre, elle lance “Vulnerability Discovery and Remediation”, un service de correction automatisée de failles s’appuyant sur les modèles Daybreak d’OpenAI. Le 15 septembre, elle modifie le comportement par défaut de vingt robots d’indexation IA dans le cadre d’une nouvelle politique de gestion des crawlers.
Ce calendrier serré illustre une tension structurelle du secteur : les fournisseurs cloud élargissent leur surface de produits (agents IA, sandboxes, conteneurs) plus vite que les audits de sécurité ne peuvent suivre. Le service Cloudflare Sandboxes, directement concerné par la faille de stockage, est justement celui que l’entreprise pousse pour héberger du code généré par IA et exécuté de façon autonome, un scénario où la confiance dans l’isolation entre locataires devient encore plus critique.
Historique : le multi-tenant cloud a déjà craqué plusieurs fois
L’incident Cloudflare Containers s’inscrit dans une lignée d’accidents d’isolation multi-tenant qui jalonne l’histoire récente du cloud. En février 2019, CVE-2019-5736 permettait à un conteneur malveillant de réécrire le binaire runc de l’hôte, ouvrant potentiellement un accès root affectant tous les autres workloads du même serveur (détails NVD). En janvier 2024, la série de failles baptisée “Leaky Vessels”, dont CVE-2024-21626 fait partie, a de nouveau touché runc et BuildKit, avec un impact potentiel sur les plateformes Docker, Kubernetes et cloud construites sur ces briques (détails NVD).
Ce que montre cette suite d’incidents sur sept ans, c’est qu’aucune couche d’isolation n’est définitivement acquise. Le passage de conteneurs “nus” partageant directement le noyau de l’hôte vers des architectures à base de micro-VM (Firecracker chez AWS, gVisor chez Google, Hyper-V chez Microsoft) a considérablement réduit la surface d’attaque classique de l’évasion de conteneur. Mais l’incident Cloudflare prouve qu’une autre couche, le stockage partagé, peut rester vulnérable même quand l’isolation d’exécution est solide. Cloudflare Containers utilise justement des machines virtuelles légères dédiées pour isoler chaque workload, une approche proche de celle de ses concurrents. Le problème ne venait donc pas d’une faiblesse dans cette isolation d’exécution, mais du pool de stockage sous-jacent partagé entre ces VM.
Comparaison technique : comment les quatre grands acteurs isolent leurs conteneurs
Pour situer l’incident, il faut comprendre comment chaque grand fournisseur cloud isole les charges de travail de ses clients. Les architectures diffèrent sensiblement, et ces choix techniques documentés publiquement expliquent pourquoi certains types de failles sont plus ou moins probables selon la plateforme.
| Fournisseur | Technologie d’isolation | Documentation officielle |
|---|---|---|
| AWS Fargate | Micro-VM Firecracker, dédiée par tâche | firecracker-microvm.github.io |
| Google Cloud Run (1ère génération) | Sandbox gVisor (namespaces Linux + filtrage syscall) | docs.cloud.google.com/run |
| Azure Container Instances | Isolation Hyper-V, groupe de conteneurs en VM légère | learn.microsoft.com/azure |
| Cloudflare Containers | Machines virtuelles légères dédiées par workload | developers.cloudflare.com/containers |
| Cloudflare Workers (rappel, produit distinct) | Isolates V8, sans conteneur ni VM | developers.cloudflare.com/workers |
Un point de confusion fréquent mérite d’être clarifié pour les lecteurs qui découvrent l’écosystème Cloudflare : Workers et Containers sont deux produits distincts. Workers exécute du code JavaScript, TypeScript ou WebAssembly dans des isolates V8, un modèle ultra-léger sans système de fichiers Linux complet. Containers, à l’inverse, fait tourner de vrais processus Linux dans des environnements basés sur des VM, destinés aux charges de travail nécessitant un runtime complet ou des paquets système. C’est ce second produit, et lui seul, qui était concerné par la faille de fuite de données résiduelles.
Impact sur le marché de la sécurité des conteneurs
L’incident survient alors que le marché mondial de la sécurité des conteneurs est en pleine expansion. Selon les estimations de Mordor Intelligence, ce marché est passé d’environ 3,06 milliards de dollars en 2025 à 3,69 milliards de dollars en 2026, avec une croissance annuelle composée projetée de 20,66 % jusqu’en 2031, année où il devrait atteindre 9,42 milliards de dollars (Mordor Intelligence, rapport 2026). D’autres cabinets d’analystes avancent des chiffres proches mais non identiques, ce qui reflète des périmètres de marché différents selon que l’on inclut ou non la sécurité Kubernetes au sens large.
Cette croissance à deux chiffres s’explique en grande partie par la multiplication des incidents de ce type. Chaque divulgation publique, même bien gérée comme celle de Cloudflare, pousse les entreprises à investir davantage dans des outils de scan de vulnérabilités, de durcissement de configuration et de surveillance runtime pour leurs environnements conteneurisés. Pour les responsables sécurité en France, l’épisode Cloudflare Containers illustre concrètement pourquoi les audits de configuration doivent désormais couvrir non seulement le code applicatif, mais aussi les couches de stockage sous-jacentes du fournisseur cloud, un périmètre souvent considéré à tort comme entièrement délégué au prestataire.
Ce que cela signifie pour le modèle de responsabilité partagée
Le cloud repose sur un principe de responsabilité partagée : le fournisseur sécurise l’infrastructure sous-jacente, le client sécurise ce qu’il déploie dessus. L’incident Cloudflare rappelle une limite de ce modèle : le client n’a strictement aucune visibilité sur la configuration du pool de stockage dm-thin de son fournisseur. Il ne peut ni l’auditer, ni la corriger, ni même savoir qu’elle existe avant qu’un chercheur externe ne la découvre. Cette asymétrie d’information est au cœur du débat sur la souveraineté cloud qui agite actuellement la Commission européenne dans le cadre du Cloud and AI Development Act, où la question de la certification indépendante des couches d’isolation des grands fournisseurs revient régulièrement sur la table.
Pour les entreprises soumises à des obligations réglementaires strictes, comme les établissements financiers sous DORA ou les opérateurs de services essentiels sous NIS2, ce type d’incident pose une question concrète : comment démontrer à un auditeur que les données de l’entreprise n’ont jamais pu fuiter vers un tiers, quand le fournisseur lui-même ne peut garantir la traçabilité complète des blocs de disque recyclés ? Cloudflare affirme n’avoir trouvé aucune preuve d’exploitation, mais l’absence de preuve n’équivaut pas à une preuve d’absence, un argument que les équipes de conformité devront probablement documenter dans leurs registres d’incidents.
Réactions de la communauté sécurité
La couverture presse spécialisée a globalement salué la transparence de Cloudflare tout en soulignant la gravité potentielle du mécanisme. Cyber Kendra a résumé l’affaire en expliquant que la faille “let any customer on a paid Workers plan read leftover data from containers that other customers had run” (Cyber Kendra, 24 septembre 2026). Cybersecurity News a de son côté détaillé le mécanisme de récupération de blocs non effacés, confirmant l’analyse technique publiée par Cloudflare (Cybersecurity News, 25 septembre 2026). La firme de recherche en sécurité Wiz, qui documente de longue date les vulnérabilités d’évasion de conteneur, rappelle dans son centre de ressources que la distinction entre fuite de données résiduelles et évasion complète reste essentielle pour évaluer correctement la sévérité d’un incident cloud (Wiz Academy).
Ce que les entreprises françaises et européennes doivent vérifier maintenant
Cloudflare affirme que le correctif est entièrement côté infrastructure et qu’aucune action client n’est requise. Cela ne dispense pas les équipes sécurité de quelques vérifications de bon sens. D’abord, identifier précisément quels workloads de l’entreprise tournent sur Cloudflare Containers ou Sandboxes, et non sur Workers, puisque seul le premier produit était concerné. Ensuite, vérifier si des données sensibles (secrets, clés API, données personnelles au sens RGPD) ont pu transiter par des volumes temporaires sur cette infrastructure entre le déploiement initial et le 19 septembre, date de la remédiation complète. Enfin, documenter l’incident dans le registre de traitement des risques fournisseurs, un exercice devenu obligatoire pour de nombreuses entités sous NIS2 depuis l’entrée en application du texte en France.
Plus largement, l’épisode invite à revoir la checklist de due diligence appliquée aux fournisseurs de compute edge et serverless. Demander explicitement comment un fournisseur gère l’effacement des blocs de stockage réutilisés entre locataires devient une question légitime lors des appels d’offres cloud, au même titre que le chiffrement au repos ou la localisation des données.
Cinq prévisions pour les prochains mois
- Les grands fournisseurs cloud (AWS, Google, Microsoft, Cloudflare) vont probablement publier des audits volontaires ou des attestations tierces sur leurs politiques d’effacement de blocs de stockage, pour désamorcer la méfiance née de cet incident.
- Le marché de la sécurité des conteneurs devrait continuer sa croissance à deux chiffres, porté par la demande d’outils de scan de configuration d’infrastructure et non plus seulement de scan d’images.
- Les régulateurs européens, dans le cadre du Cyber Resilience Act et des discussions sur le Cloud and AI Development Act, devraient renforcer les exigences de divulgation rapide pour les incidents d’isolation multi-tenant, même en l’absence de CVE formel.
- D’autres fournisseurs de compute edge proposant des sandboxes pour agents IA, au-delà de Cloudflare, devraient faire l’objet d’audits de sécurité accrus, la mode des agents de codage IA hébergés augmentant mécaniquement la surface d’attaque multi-tenant.
- Les grands comptes financiers et publics français vont vraisemblablement intégrer une clause contractuelle spécifique sur l’effacement garanti des données résiduelles dans leurs prochains contrats cloud, en particulier ceux soumis à DORA.
Le point de vue des architectes cloud
Du point de vue d’un architecte cloud, cet incident renforce un principe déjà connu mais souvent négligé en pratique : ne jamais faire confiance implicitement à l’isolation d’un fournisseur pour des données véritablement sensibles, même chiffrées au repos. Le chiffrement applicatif de bout en bout, indépendant de la couche de stockage du fournisseur, reste la seule protection qui aurait rendu les blocs résiduels totalement inutiles pour un attaquant, même en cas de récupération réussie. Les équipes qui déploient des workloads sur des plateformes de compute mutualisées, qu’il s’agisse de Cloudflare Containers, d’AWS Fargate ou de Google Cloud Run, ont donc intérêt à traiter le chiffrement applicatif comme une couche de défense en profondeur plutôt que comme une option réservée aux données les plus critiques.
Foire aux questions
Un CVE a-t-il été attribué à cette faille Cloudflare Containers ?
Non. Aucun identifiant CVE n’a été publié, car la faille résidait dans une configuration interne propriétaire de Cloudflare (le pool de stockage dm-thin), et non dans un logiciel versionné et distribué publiquement.
Mes données ont-elles été compromises si j’utilise Cloudflare Workers ?
Non, si vous utilisez uniquement Cloudflare Workers (isolates V8) sans le produit Containers ou Sandboxes, vous n’étiez pas exposé à cette faille spécifique, qui touchait exclusivement le stockage disque des conteneurs Linux.
Cloudflare a-t-il confirmé une exploitation malveillante de la faille ?
Non. Cloudflare déclare explicitement n’avoir trouvé aucune preuve qu’un acteur malveillant ait exploité la vulnérabilité en dehors des tests du chercheur qui l’a signalée.
Quelle est la différence entre cette faille et un “container escape” classique ?
Un container escape permet à un attaquant de sortir de son environnement isolé pour prendre le contrôle du serveur hôte. Ici, aucune évasion n’a été démontrée : il s’agissait d’une fuite de données résiduelles laissées sur des blocs de disque réattribués, sans compromission du système hôte.
Dois-je faire une action spécifique si j’utilise Cloudflare Containers ?
Selon Cloudflare, aucune action côté client n’est requise, la remédiation ayant été appliquée entièrement à l’infrastructure. Il reste toutefois recommandé de documenter l’incident dans son registre de risques fournisseurs si votre organisation est soumise à NIS2 ou DORA.
Ce type de faille peut-il aussi toucher AWS Fargate, Azure Container Instances ou Google Cloud Run ?
Ces trois services utilisent des technologies d’isolation différentes (Firecracker, Hyper-V, gVisor) documentées publiquement. Aucun des trois n’a annoncé d’incident similaire en 2026 à ce jour, mais le mécanisme de fond, la réutilisation de blocs de stockage sans effacement, est un risque générique applicable à toute infrastructure de stockage partagé thin-provisioned, quel que soit le fournisseur.
Comment Cloudflare a-t-il corrigé le problème techniquement ?
L’entreprise a retiré l’option skip_block_zeroing de la configuration du pool dm-thin sur l’ensemble de son parc, rétablissant l’effacement systématique des blocs avant réattribution, puis a retiré et recréé les disques existants ainsi que les snapshots en cache.
Où trouver le bulletin officiel de Cloudflare sur cet incident ?
Le billet complet est disponible sur le blog officiel de l’entreprise, sous le titre “How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers”, publié le 24 septembre 2026, à l’adresse blog.cloudflare.com/containers-cross-tenant-vulnerability/.
