Cloudflare corrige une faille qui laissait un conteneur lire les données d’un autre client
Le 24 septembre 2026, Cloudflare a révélé qu’un réglage de thin provisioning dans Cloudflare Containers permettait à un client de lire les données qu’un autre client avait laissées sur le même serveur. Les clients n’ont rien à faire, mais la faille rappelle que l’isolation multi-locataire, promise par le cloud, tient parfois à un paramètre par défaut.
4 septembre 2026. Oren Yomtov, chercheur chez Accomplish, signale à Cloudflare qu’un client payant peut lire les données qu’un autre client a laissées sur le même serveur. 19 septembre 2026. Cloudflare termine la purge de tous les disques de conteneurs encore en service. 24 septembre 2026. La faille est rendue publique. Pourquoi c’est important : l’isolation multi-locataire est la promesse fondatrice du cloud — et ici, un simple réglage de provisioning a suffi à la rompre, sans que personne ne s’en aperçoive pendant des semaines.
Ce qui a fui, et ce qui n’a pas fui
La faille touche Cloudflare Containers, le service qui exécute les programmes des clients dans des conteneurs sur des serveurs partagés entre de nombreux comptes. Elle touche aussi Cloudflare Sandboxes, le produit construit au-dessus et vendu comme un endroit sûr pour exécuter du code non fiable — y compris celui écrit par des agents IA.
Ce qui a fui n’est pas anodin : des structures de répertoires, des pages de base de données, des bases SQLite complètes, des profils Chromium, des fichiers .env et des fichiers de credentials. Mais il faut être précis sur la nature de la fuite. Les données provenaient de l’espace disque que des conteneurs précédents avaient utilisé puis restitué — pas de charges de travail vivantes. Et l’attaquant ne pouvait pas choisir à qui appartenaient les données qu’il récupérait : il lisait ce que le disque voulait bien lui rendre, à l’aveugle.
C’est une distinction capitale pour le verdict. Personne n’a démontré qu’on pouvait modifier les données vivantes d’un autre client ni mettre hors service une charge de travail. La faille est une fuite passive de restes, pas une prise de contrôle.
La cause : un bloc de 64 Ko qu’on oublie d’effacer
Le mécanisme est d’une banalité presque embarrassante. Chaque conteneur reçoit un disque construit avec une fonctionnalité Linux nommée thin provisioning, qui alloue le stockage par blocs de 64 Ko. À la suppression d’un conteneur, ses blocs retournent dans un pool partagé entre les comptes clients.
Le problème est là : ce pool était configuré pour sauter l’effacement d’un bloc avant de le remettre au conteneur suivant — alors que l’effacement est normalement le comportement par défaut. Résultat, quand un nouveau conteneur n’écrivait qu’une petite quantité dans un bloc réutilisé, le reste du bloc conservait les données du conteneur précédent.
Pour le prouver, les chercheurs ont écrit un bloc de 4 Ko dans un espace inutilisé, puis relu le bloc entier au niveau du disque brut. Les 60 Ko qu’ils n’avaient pas écrits contenaient encore les octets d’un conteneur antérieur. En production, ils ont retrouvé des restes lors de 18 essais sur 24, et sur 20 des 22 machines sous-jacentes, réparties sur quatre continents.
Le chiffre qui compte n’est pas la taille des blocs, mais la régularité : la fuite n’était pas un accident isolé, elle était structurelle.
Une correction en deux temps, puis cinq jours de silence
Cloudflare a corrigé en deux étapes. D’abord, il a réactivé l’effacement pour les blocs nouvellement attribués, ce qui a neutralisé la méthode signalée — les chercheurs ont confirmé le 14 septembre que leur preuve de concept ne fonctionnait plus.
Mais cette première étape ne nettoyait pas les blocs déjà mappés dans les disques des conteneurs en cours d’exécution, ni le cache des couches d’images préparées qu’un nouveau conteneur pouvait hériter. Cloudflare a donc retiré tous les disques de conteneurs en service et vidé ces caches, en drainant et redémarrant des serveurs pendant les heures creuses. L’opération s’est achevée le 19 septembre ; la divulgation publique a suivi cinq jours plus tard.
Cloudflare affirme avoir construit des signatures de détection à partir de la preuve de concept et de sa propre reproduction de l’attaque, puis les avoir passées sur les journaux d’activité disque conservés. Résultat : seuls les tests autorisés des chercheurs et de ses propres ingénieurs apparaissent, et aucun indice qu’une autre personne ait utilisé cette méthode. Une limite demeure : l’entreprise n’indique ni la période couverte par ces journaux, ni depuis quand le réglage dangereux était en place. La durée réelle de l’exposition reste donc inconnue.
La sixième évasion de sandbox depuis juillet
Les chercheurs replacent cette découverte dans une série : c’est leur sixième évasion de sandbox de code publiée depuis juillet, après des résultats chez Claude Cowork et Claude Code d’Anthropic, l’outil en ligne de commande de Cursor, Docker et Codex d’OpenAI. Ils précisent en outre que la même configuration de disque affectait Cloudflare Browser Run.
Cette accumulation n’est pas anecdotique. Elle dit quelque chose de la vitesse à laquelle le secteur déploie des sandboxes pour exécuter du code d’agent IA : la demande explose, et les couches d’isolation, souvent héritées de briques d’infrastructure classiques, sont réutilisées plus vite qu’elles ne sont durcies.
Pourquoi la fuite est passée inaperçue
La faille a duré des semaines sans déclencher d’alerte, et c’est précisément ce qui la rend instructive.
Le thin provisioning n’efface jamais physiquement un bloc libéré : rendre un bloc au pool est une opération comptable, pas un nettoyage. L’effacement qui aurait dû précéder la réaffectation est une étape distincte — et c’est elle que le réglage avait désactivée. Tant que personne ne relit un bloc au niveau du disque brut, le résidu reste invisible.
La surveillance classique n’y voit rien non plus. Un conteneur qui lit les restes d’un autre locataire produit une activité d’entrée-sortie tout à fait banale sur un disque partagé : rien ne distingue cette lecture d’une lecture légitime. Les chercheurs n’ont trouvé la faille que parce qu’ils ont écrit un bloc de 4 Ko délibérément petit, puis relu le bloc de 64 Ko entier — une manœuvre qu’aucun agent de supervision du commerce ne pratique.
Le réglage lui-même est une dérive de configuration classique. Un pool de thin provisioning se crée une fois, par des ingénieurs d’infrastructure, avec la performance en tête : sauter l’effacement économise une écriture à chaque passage de main, et ressemble à une micro-optimisation sans conséquence au moment où on la fait. Aucun propriétaire d’application ne la voit jamais, et aucun test applicatif ne la détecterait, parce que la faille vit une couche sous le runtime de conteneur. C’est aussi pourquoi la correction a exigé une seconde étape : même une fois l’effacement rétabli, chaque disque déjà mappé et chaque couche d’image en cache a dû être démonté et reconstruit. Un correctif de configuration ne suffisait pas — l’état devait être purgé physiquement.
Reste la question de la durée. Cloudflare n’a indiqué ni depuis quand le réglage dangereux était actif, ni la période couverte par les journaux qu’il a analysés. Sa détection n’a trouvé qu’une exploitation autorisée, mais cette conclusion ne vaut que pour les enregistrements conservés. Une plateforme qui ne peut pas borner la fenêtre d’exposition ne peut pas, non plus, borner le risque — et c’est la première chose qu’un client exigeant devrait demander dans un rapport post-incident.
Verdict
Si vous êtes client de Cloudflare Containers ou Sandboxes, vous n’avez rien à faire : la correction est déployée et Cloudflare assure n’avoir trouvé aucune exploitation tierce. Si vous concevez une plateforme multi-locataire, retenez la leçon du bloc de 64 Ko : auditez vos réglages de thin provisioning, ne présumez jamais que l’effacement est actif par défaut, et testez vous-même la présence de restes inter-locataires — un test de quatre kilo-octets suffit. Si vous exécutez des agents IA dans des sandboxes tierces, considérez que l’isolation protège l’hôte, pas votre environnement : ne placez jamais de secrets dans un fichier qu’une sandbox peut lire, et traitez toute exécution comme potentiellement voisine d’un autre locataire.