L’essentiel
Un paramètre de stockage de Cloudflare Containers ne remettait pas à zéro les blocs disque réutilisés : un nouveau conteneur pouvait donc lire des fragments laissés par le conteneur supprimé d’un autre client. Cloudflare a corrigé le problème en quelques jours, n’a trouvé aucune trace d’abus et n’exige aucune action. Si vous exécutez des charges sur Cloudflare Workers et son runtime de conteneurs, retenez une chose : un disque supprimé n’est jamais forcément vide.
Considérez tout disque cloud partagé comme non fiable dès que vous le libérez, et n’y stockez pas de secrets au départ.
Qu’a révélé Cloudflare ?
Le 24 septembre 2026, Cloudflare a publié un post-mortem sur une exposition de données entre locataires dans Containers, son runtime de conteneurs associé à Workers, ainsi que dans Sandboxes, qui exécute du code non fiable comme les tâches d’agents IA. Selon l’entreprise, un client Workers Paid aurait pu récupérer des données résiduelles dans des blocs de stockage précédemment utilisés par les conteneurs d’autres clients sur le même hôte.
Le chercheur en sécurité Oren Yomtov, d’Accomplish, a signalé le problème via le programme HackerOne de Cloudflare le 4 septembre à 15 h 26 UTC. Cloudflare l’a confirmé en production environ trois heures plus tard et a fusionné un correctif du runtime dans la soirée. BleepingComputer et The Hacker News ont relayé la divulgation dans les jours suivants.
D’après Cloudflare, les blocs récupérés contenaient des arborescences de répertoires, des pages de bases de données et des bases SQLite structurellement complètes. Le compte rendu des chercheurs, tel que résumé par les deux médias, mentionne aussi des profils de navigateur Chromium, des fichiers .env et des fichiers d’identifiants. Les chercheurs affirment que leurs scripts ne renvoyaient que des décomptes agrégés, pas le contenu des fichiers.
Comment les données passaient-elles d’un client à l’autre ?
Les disques des conteneurs étaient découpés dans un pool partagé grâce au thin provisioning du device-mapper Linux. L’option skip_block_zeroing y était activée : le noyau ne remet pas à zéro un bloc nouvellement alloué avant de l’attribuer. Les blocs faisaient 64 Kio. Lorsqu’un nouveau conteneur n’écrivait que quelques kilo-octets dans un bloc fraîchement attribué, le reste contenait encore ce que le propriétaire précédent y avait écrit.
Ne pas remettre à zéro est un compromis de performance courant, car effacer chaque bloc coûte des E/S. C’est sans danger quand un seul locataire possède le pool, risqué quand ils sont nombreux. Le correctif de Cloudflare a supprimé l’option, retiré tous les disques de conteneurs créés avant la mitigation, vidé les snapshots d’images en cache, puis drainé et redémarré les hôtes aux heures creuses.
Deux limites réduisaient le risque : un attaquant ne pouvait ni choisir sa victime, ni lire un disque encore attaché à un conteneur en cours d’exécution. Seul ce qui traînait sur l’espace libéré pouvait fuiter.
Qu’est-ce que cela change pour les équipes logicielles ?
D’abord, « supprimé » ne veut pas dire « effacé » sur une infrastructure partagée. C’est la même famille de bugs que les données résiduelles dans les volumes cloud réutilisés ou la mémoire GPU, et elle réapparaîtra chez d’autres fournisseurs. Votre modèle de menace pour toute plateforme multi-locataire, y compris les produits Cloudflare les plus récents, doit supposer que le stockage libéré peut être lu par quelqu’un d’autre.
Ensuite, les sandboxes pour agents IA augmentent l’enjeu. Les équipes exécutent de plus en plus de code généré par des agents, de sessions de navigateur et de bases temporaires dans des conteneurs éphémères. Ce sont précisément les données exposées ici : profils de navigateur, fichiers SQLite locaux et fichiers .env contenant des clés d’API. Éphémère ne signifie pas sans risque si le disque survit au conteneur.
Enfin, la conformité repose toujours sur vos propres contrôles. Cloudflare n’ayant constaté aucun abus, il ne s’agit pas d’une violation à notifier pour la plupart des clients. Mais au titre du RGPD, de HIPAA ou de SOC 2, vous devez démontrer que les données personnelles et les identifiants restent protégés même si l’isolation du fournisseur échoue. Le chiffrement applicatif et des identifiants à courte durée de vie permettent de l’affirmer.
Qu’est-ce que cela signifie pour le marché français ?
En France, la question de l’isolation entre locataires est au cœur des achats cloud sensibles : les administrations et les opérateurs d’importance vitale s’appuient sur la qualification SecNumCloud de l’ANSSI, dont les exigences portent justement sur le cloisonnement et l’effacement sécurisé des données. Le cas Cloudflare rappelle qu’un choix de performance au niveau du stockage peut contourner ces garanties sans qu’aucun processus ne soit visiblement défaillant.
Côté conformité, la CNIL attend du responsable de traitement qu’il documente toute violation potentielle, même non notifiée au titre de l’article 33 du RGPD. Consignez donc votre analyse de cet incident dans votre registre, vérifiez si des données personnelles ou des identifiants résidaient sur les conteneurs concernés, et intégrez l’effacement des disques libérés à vos clauses de sous-traitance (article 28). Pour les ETI et scale-ups qui déploient des agents IA en sandbox, c’est souvent le chantier le plus rapide à fermer avant un audit.
Que faire maintenant ?
- Aucun correctif d’urgence n’est nécessaire. Cloudflare a appliqué le correctif sur toute la plateforme ; vous n’avez rien à mettre à jour.
- Inventoriez ce que vos conteneurs écrivent sur disque. Listez les charges Containers ou Sandboxes qui stockent des bases de données, profils de navigateur, jetons en cache ou fichiers
.envsur le disque racine. - Faites tourner les secrets de longue durée par précaution. Si un conteneur a fonctionné avant le 7 septembre 2026 avec des clés d’API ou des mots de passe de base de données sur disque, les renouveler est une assurance peu coûteuse.
- Gardez les secrets hors du système de fichiers. Injectez les identifiants à l’exécution depuis un gestionnaire de secrets avec un TTL court, plutôt que de les intégrer aux images ou de les écrire sur disque.
- Chiffrez les données temporaires sensibles. Pour les charges qui doivent écrire localement des données personnelles ou financières, chiffrez-les avec une clé par charge : les blocs résiduels deviennent inexploitables pour quiconque.
Questions fréquentes
Quelle était la vulnérabilité de Cloudflare Containers ?
Cloudflare Containers et Sandboxes stockaient les disques des conteneurs dans un pool partagé en thin provisioning, configuré pour ne pas remettre à zéro les blocs de 64 Kio réutilisés. Quand le conteneur d’un client était supprimé, ses blocs retournaient au pool sans être effacés, et un nouveau conteneur appartenant à un autre client Workers Paid sur le même hôte pouvait lire les données restantes.
Des données clients ont-elles été volées ?
Cloudflare indique n’avoir trouvé aucune preuve d’exploitation malveillante dans sa télémétrie d’E/S disque ; la seule activité observée provenait des chercheurs et de ses propres ingénieurs. Les chercheurs affirment que leurs scripts renvoyaient des décomptes agrégés et non le contenu des fichiers. Un attaquant ne pouvait pas non plus choisir sa victime ni lire un disque encore attaché à un conteneur actif.
Les clients de Cloudflare doivent-ils agir ?
Non. Selon Cloudflare, la vulnérabilité est corrigée et la remédiation ne nécessite aucune action des clients. Les équipes qui stockaient des secrets de longue durée ou des bases sensibles sur les disques des conteneurs peuvent toutefois renouveler ces identifiants par précaution.
Quand la faille a-t-elle été signalée et corrigée ?
Oren Yomtov, d’Accomplish, l’a signalée via HackerOne le 4 septembre 2026. Cloudflare a fusionné un correctif du runtime le jour même, terminé le déploiement le 7 septembre, achevé le nettoyage des snapshots le 19 septembre et publié sa divulgation le 24 septembre 2026.
Faut-il notifier la CNIL ?
Pour la plupart des clients, non : Cloudflare n’a constaté aucun abus et n’exige aucune action. Il reste recommandé de documenter l’analyse de l’incident dans votre registre des violations et de vérifier si des données personnelles ou des identifiants se trouvaient sur les conteneurs concernés.
Sources
Cloudflare Blog — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers (24 septembre 2026)
BleepingComputer — Cloudflare fixes Containers cross-tenant flaw exposing customer data
The Hacker News — Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data