Cloudflare efface les disques de conteneurs réutilisés après une faille ayant entraîné une fuite de données entre clients

Cloudflare a corrigé une faille d’isolation du stockage dans Cloudflare Containers. Celle-ci permettait à la charge de travail d’un client de récupérer des fragments de disque laissés par un autre client sur la même infrastructure physique.

La faille concernait également Cloudflare Sandboxes, un service reposant sur Containers pour exécuter du code non fiable, notamment des programmes générés par des agents d’IA. Le problème exposait des données résiduelles d’applications, et non du stockage actif encore rattaché à une charge de travail. Les tests ont toutefois montré que des blocs récupérables étaient présents sur une grande partie des systèmes de production examinés.

Cloudflare a appliqué les correctifs automatiquement et achevé le nettoyage de son infrastructure le 19 septembre 2026. Les clients n’ont aucune action à entreprendre.

Des blocs réattribués franchissaient la frontière entre clients

Cloudflare Containers exécute des charges de travail conteneurisées pour les clients disposant d’un compte Workers Paid. Le service est notamment utilisé pour des applications backend, le traitement de tâches et l’exécution isolée de code.

Cloudflare détermine où s’exécute chaque conteneur, tandis que plusieurs comptes clients partagent les serveurs et les ressources de stockage sous-jacents du fournisseur. Cette architecture exige une séparation stricte entre les charges de travail actives, mais aussi au moment où le stockage est libéré puis attribué à un autre client.

Le chercheur en sécurité d’Accomplish Oren Yomtov a signalé le problème le 4 septembre via le programme de chasse aux bugs de Cloudflare, identifié par BleepingComputer comme HackerOne.

La faille se manifestait à la suppression d’un conteneur. Ses blocs de disque physiques retournaient dans un pool partagé, où ils pouvaient ensuite être attribués à des conteneurs appartenant à des comptes sans lien avec le précédent. Ce pool était configuré pour ne pas effacer les blocs avant leur réutilisation, alors que leur mise à zéro était normalement le comportement par défaut.

Par conséquent, l’attribution d’un bloc à un nouveau client ne garantissait pas que chaque octet avait été effacé. Les parties non modifiées par la nouvelle charge de travail pouvaient encore contenir des informations écrites par l’utilisateur précédent.

Une écriture de 4 Kio révélait le reste d’un bloc de 64 Kio

Le stockage concerné reposait sur le provisionnement fin de Linux et allouait l’espace disque par blocs de 64 Kio. Le provisionnement fin associe le stockage logique à l’espace physique au fur et à mesure des besoins, ce qui évite de réserver à l’avance la totalité de l’espace disque demandé.

Les chercheurs ont démontré une conséquence directe du décalage entre la taille des blocs alloués et celle des écritures. Un nouveau conteneur pouvait écrire 4 Kio dans une zone disque autrement inutilisée, puis examiner l’intégralité du bloc physique de 64 Kio au moyen d’un accès au disque brut.

La nouvelle écriture remplaçait les 4 premiers Kio. Les 60 Kio restants pouvaient conserver des données provenant d’un conteneur supprimé auquel le même bloc physique avait été attribué auparavant.

Il ne s’agissait pas d’un accès classique aux fichiers via le système de fichiers monté d’un autre client. L’attaquant examinait plutôt le stockage récupéré à un niveau inférieur à cette abstraction, à la recherche de structures reconnaissables dans les octets laissés sur le disque.

Cloudflare a indiqué qu’une exploitation réussie aurait constitué une violation de la frontière d’isolation entre clients. Les éléments potentiellement exposés comprenaient :

• Des métadonnées et des structures de répertoires du système de fichiers
• Des pages de bases de données et des structures complètes de bases de données SQLite
• Des données d’application
• Des profils du navigateur Chromium
• Des fichiers .env
• Des fichiers contenant des identifiants

Les résultats montrent que les informations sensibles n’avaient pas besoin de figurer dans un fichier ordinaire complet pour être exploitables. Des pages de base de données, des fragments de configuration ou des entrées de répertoire peuvent révéler des secrets et des détails opérationnels, même s’ils ne sont récupérés que partiellement.

Des tests en production ont révélé des résidus sur la plupart des nœuds échantillonnés

Les chercheurs ont détecté des données résiduelles dans 18 des 24 environnements où des conteneurs avaient été placés. Ils en ont également trouvé sur 20 des 22 machines ou nœuds sous-jacents inclus dans leurs tests, répartis sur quatre continents, selon les informations publiées sur la divulgation de Cloudflare et les résultats des chercheurs.

Cloudflare a indiqué que les blocs récupérés comprenaient des structures de répertoires, des pages de bases de données et des bases de données SQLite structurellement complètes. Les chercheurs ont également signalé avoir reconnu des profils de navigateur, des fichiers d’environnement et des fichiers liés à des identifiants.

Leurs scripts d’analyse ont produit des décomptes agrégés et validé les formats de données, sans collecter le contenu des fichiers. Ils ont précisé que leur signalement à Cloudflare ne contenait aucun nom, identifiant ou identifiant d’authentification appartenant à des tiers, ni aucun contenu client récupéré. Les éventuelles données récupérées ont été conservées de manière confidentielle et supprimées de façon sécurisée après le signalement.

Cloudflare affirme qu’aucune donnée réelle de client n’a été exposée pendant l’évaluation autorisée. De leur côté, les chercheurs indiquent avoir récupéré des données résiduelles lors des tests. Ces déclarations portent sur des aspects différents de l’exercice : les tests ont établi que d’anciennes structures de données restaient accessibles, tandis que les chercheurs affirment avoir évité de conserver ou de transmettre tout contenu identifiable appartenant à des tiers.

La faille permettait une divulgation, pas la prise de contrôle d’autres charges de travail

L’impact démontré se limitait à la confidentialité. Les chercheurs n’ont pas montré qu’un attaquant pouvait modifier les fichiers actifs d’un autre client, interrompre un service ou prendre le contrôle du conteneur d’une victime.

La méthode ne permettait pas non plus de lire un disque tant qu’il restait activement rattaché à une autre charge de travail. L’exploitation dépendait de la libération de blocs physiques, puis de leur réattribution via le pool de stockage partagé.

Un attaquant ne pouvait pas non plus choisir une victime précise. Cloudflare contrôlait le placement des conteneurs, et les blocs réutilisés disponibles pour une nouvelle charge de travail dépendaient des décisions d’allocation de l’infrastructure. Un attaquant pouvait donc rechercher des données résiduelles, mais pas demander l’accès à un espace de stockage précédemment attribué à une organisation donnée.

Cette limite réduit la précision de la méthode, mais pas la sensibilité des données susceptibles d’être découvertes. Les secrets présents dans des fichiers .env, des magasins d’identifiants ou des pages de bases de données pouvaient rester précieux, quel que soit le client qui les avait créés à l’origine.

Les chercheurs ont également indiqué que Cloudflare Browser Run utilisait la même configuration de disque. Le périmètre divulgué par Cloudflare mentionnait Containers et Sandboxes, mais pas Browser Run. Il n’est donc pas établi si Cloudflare considère Browser Run comme un service également touché ou si sa correction a nécessité des mesures supplémentaires propres à ce service.

Cloudflare n’a relevé aucun signe d’exploitation en dehors des tests

Après avoir reproduit le problème, Cloudflare a créé des signatures de détection à partir de la preuve de concept des chercheurs et de ses propres tests. L’entreprise a ensuite passé au crible les journaux d’activité des disques conservés à la recherche de comportements correspondants.

Cloudflare n’a détecté que les activités autorisées menées par les chercheurs et ses propres ingénieurs. L’examen des journaux, de la télémétrie et des données historiques n’a, selon l’entreprise, révélé aucun signe qu’un tiers ait utilisé la même technique pour exposer des données clients.

Les informations disponibles ne précisent toutefois pas jusqu’à quelle date remontaient les journaux conservés. Cloudflare n’a pas non plus indiqué quand la configuration dangereuse, qui désactivait la mise à zéro, avait été introduite. La période pendant laquelle des blocs résiduels ont pu être récupérés reste donc inconnue.

Aucun indicateur de compromission public n’a été fourni pour permettre aux clients de mener leurs propres recherches. Les éléments pertinents se trouvant dans l’infrastructure de stockage et les systèmes de placement de Cloudflare, les utilisateurs disposent peut-être de peu de moyens pour savoir si les blocs de leurs conteneurs supprimés ont été réattribués.

La correction de l’allocation n’était que la première étape

Cloudflare a d’abord rétabli la mise à zéro des blocs nouvellement alloués. Ainsi, tout espace de stockage attribué après le correctif était effacé avant de devenir accessible à un autre client.

Le 14 septembre, les chercheurs ont confirmé que leur preuve de concept ne fonctionnait plus. Mais la modification de la politique d’allocation n’a pas supprimé toutes les associations historiques déjà présentes sur la plateforme.

Des blocs pouvaient rester associés aux disques de conteneurs en cours d’exécution. Des couches d’images préparées et des instantanés en cache pouvaient également conserver d’anciennes associations. Cloudflare a donc retiré tous les disques de conteneurs actifs et vidé les caches concernés, en drainant puis en redémarrant les serveurs pendant les périodes de moindre activité.

L’entreprise a achevé ce nettoyage le 19 septembre 2026. La correction ayant été déployée au sein de l’infrastructure de Cloudflare, les clients n’ont pas besoin de corriger leurs applications, de renouveler leurs images de conteneurs ni de modifier leur configuration.

Aucun identifiant CVE ni niveau de gravité officiel n’a été publié. Il s’agit avant tout d’une défaillance de confidentialité entre clients, susceptible d’exposer des données résiduelles sensibles, et non d’une prise de contrôle de l’hôte ou d’une évasion destructive de conteneur.

Les chercheurs ont présenté ce cas comme leur sixième évasion publiée d’un bac à sable d’exécution de code depuis juillet, après leurs travaux sur Claude Cowork et Claude Code d’Anthropic, l’outil en ligne de commande de Cursor, Docker et Codex d’OpenAI. Dans ce cas précis, toutefois, la capacité démontrée se limitait à récupérer le contenu de disques réattribués, et non à prendre le contrôle arbitraire d’un autre client ou de l’hôte Cloudflare.