Cloudflare ha corregido une vulnérabilité sur sa plateforme Containers pouvant compromettre l’isolation entre clients en raison de la réutilisation de blocs de stockage physique. Un chercheur a réussi à récupérer des données résiduelles appartenant à d’autres conteneurs hébergés dans le même environnement, en exploitant une configuration de dm-thin qui ne vidait pas complètement les blocs avant leur réaffectation.

Les clés de la vulnérabilité de Cloudflare Containers en 20 secondes

• La faille se situait au niveau de la couche de stockage et concernait des blocs physiques de 64 Ko.
• Une écriture de seulement 4 Ko pouvait exposer les 60 Ko restants.
• Les tests ont permis de récupérer des structures de répertoires et des données liées à des bases de données.
• Le chercheur a trouvé du matériel résiduel dans 18 des 24 emplacements analysés.
• Cloudflare a retiré la configuration vulnérable, supprimé les snapshots anciens, et n’a pas détecté d’exploitation malveillante.

L’incident a été signalé à Cloudflare le 4 septembre 2026 par Oren Yomtov, chercheur chez Accomplish, dans le cadre du programme de récompenses de sécurité de l’entreprise. Cloudflare affirme avoir corrigé le problème et que ses investigations n’ont pas révélé d’usage de la vulnérabilité par des tiers contre ses clients.

Cette faille touchait Cloudflare Containers et, indirectement, Cloudflare Sandboxes, construit sur la même technologie. La situation était particulièrement critique dans un environnement multi-locataires : différents clients pouvaient finir par utiliser des blocs physiques issus du même pool de stockage.

L’enquête a démontré que l’isolation logique entre conteneurs ne suffisait pas à empêcher la présence de restes d’informations de propriétaires précédents dans certaines conditions.

Une écriture de 4 Ko pouvait exposer 60 Ko de données

Cloudflare utilise dm-thin, le système d’allocation légère de Linux, pour fournir des disques racine écrits à ses conteneurs. Chacun fonctionne dans une machine virtuelle basée sur Firecracker et reçoit le stockage via le dispositif /dev/vdc.

Ce système ne réserve pas tout l’espace physique à l’avance. Les blocs sont alloués lorsque une zone spécifique du disque virtuel reçoit une écriture.

Les pools affectés utilisaient des blocs physiques de 64 Ko. Lorsqu’un disque de conteneur était supprimé, ces blocs pouvaient revenir dans le pool partagé et être réaffectés à une autre charge de travail.

La configuration problématique comprenait skip_block_zeroing. Cette option empêchait dm-thin de nettoyer le bloc physique avant de le mettre à disposition d’un nouveau volume.

Ce comportement avait une conséquence précise. Si le nouveau conteneur écrivait l’entier des 64 Ko, les données précédentes étaient remplacées. En revanche, si il n’écrivait que 4 Ko, alors les 60 Ko restants n’écrasés pouvaient conserver des informations antérieures.

Le chercheur a élaboré une preuve de concept pour repérer des régions libres dans le système de fichiers ext4, écrire 4 Ko dans des blocs alignés, puis vérifier si des données issues d’un propriétaire précédent apparaissaient dans les zones non sobrescrites.

La lecture directe du dispositif permettait alors d’observer des données que le nouveau conteneur n’avait jamais générées lui-même.

Le chercheur a même identifié des blocs appartenant à d’autres systèmes de fichiers

L’enquête ne s’est pas limitée à constater la présence de bytes résiduels. Pour différencier leurs propres données de celles provenant d’autres systèmes de fichiers, l’équipe a utilisé les sommes de contrôle des blocs de répertoires d’ext4.

Selon Cloudflare, les chercheurs ont étudié 5 614 blocs de répertoires dans six localisations en production. Aucun ne correspondait au système de fichiers utilisé lors de leurs tests.

L’analyse a aussi permis d’identifier 2 700 inodes de répertoires associés par vérification à d’autres systèmes de fichiers.

Les chercheurs ont retrouvé du matériel résiduel dans 18 des 24 emplacements analysés, ainsi que dans 20 des 22 nœuds sous-jacents, répartis sur quatre continents. Parmi les types d’informations retrouvées figurent des structures de répertoires, des pages de bases de données, et des bases SQLite complètes sur le plan structurel.

Cependant, l’ampleur de la découverte avait ses limites : la technique ne permettait pas de cibler un client spécifique ni d’accéder directement à un disque actif d’une autre organisation. La vulnérabilité reposait sur la réaffectation de blocs déjà utilisés et conservant des données résiduelles.

Il n’a pas été prouvé non plus que cette méthode pouvait modifier des données actives d’un autre client ou perturber la disponibilité de ses charges de travail.

Plus qu’une simple correction de configuration

La première étape de Cloudflare a été de supprimer skip_block_zeroing des pools dm-thin. Ainsi, les nouvelles affectations rétablissaient le comportement de nettoyage des blocs avant leur mise à disposition.

Mais la société a aussi constaté que corriger ces nouvelles allocations ne suffisait pas à éliminer les éventuels résidus déjà présents sur les disques ou caches existants.

Certains blocs pouvaient rester mappés sur des disques de conteneurs en fonctionnement. De plus, des hôtes conservaient en cache des snapshots préemballés pour des couches d’images OCI. Un nouveau conteneur pouvait hériter de ces mappages sans nécessiter une nouvelle allocation physique.

C’est pourquoi Cloudflare a décidé de retirer les disques des conteneurs affectés, ainsi que les snapshots en cache créés avant la correction.

L’opération a impliqué la purge des hôtes, le redémarrage des machines virtuelles, et le nettoyage des caches d’images. Ensuite, de nouveaux ressources ont été créées avec des allocations de blocs correctement initialisés.

L’entreprise affirme avoir terminé la purge des snapshots anciens avant la mitigation le 19 septembre 2026.

Aucune exploitation malveillante n’a été détectée

Cloudflare a également examiné la télémétrie historique de ses opérations disque pour détecter toute activité anormale susceptible d’avoir exploité cette faille.

Des signatures de détection ont été élaborées, basées sur le comportement observé durant la preuve de concept. Le pattern comprenait des écritures de 4 Ko pouvant provoquer la réaffectation de blocs de 64 Ko, suivies de lectures susceptibles de récupérer des données hors de la zone sobrescrite.

L’analyse a identifié une activité liée uniquement aux tests autorisés, réalisés par des chercheurs et ingénieurs internes. Aucun signe d’utilisation non autorisée n’a été repéré, selon la société.

Ainsi, Cloudflare certifie qu’aucune exploitation malveillante n’a été détectée concernant cette vulnérabilité.

Ce cas souligne l’importance de plusieurs couches de sécurité dans les environnements multi-locataires. Même si le conteneur est isolé logiquement, une configuration erronée au niveau du stockage physique peut faire naître un vecteur d’attaque pour récupérer des données résiduelles d’autres clients.

La correction démontre aussi qu’un changement de configuration doit souvent s’accompagner de mesures additionnelles lorsqu’on gère des ressources persistantes, caches ou snapshots préexistants. Dans ce cas, Cloudflare n’a pas seulement modifié dm-thin : elle a aussi supprimé et recréé certains ressources susceptibles de conserver des assignations antérieures.

Selon Cloudflare, la vulnérabilité a été corrigée sans exiger de modification de la part de ses clients. La société a également exprimé sa gratitude envers le chercheur et le groupe Accomplish pour leur communication responsable.

Questions fréquentes

Que permettait cette vulnérabilité de Cloudflare Containers ?

Elle pouvait permettre à un client de récupérer des données résiduelles issues des blocs de stockage précédemment utilisés par d’autres conteneurs dans le même environnement physique.

Pourquoi une écriture de 4 Ko était-elle suffisante ?

Les blocs physiques impliqués faisaient 64 Ko. Comme la configuration n’effaçait pas le bloc complet avant réutilisation, une écriture de seulement 4 Ko pouvait laisser les 60 Ko restants avec des données résiduelles.

Quelles informations ont été découvertes par les chercheurs ?

Ils ont identifié des structures de répertoires, pages de bases de données, et bases SQLite complètes, ainsi que d’autres données résiduelles issues de systèmes de fichiers.

Cloudflare a-t-elle confirmé une tentative d’attaque ?

Non. Cloudflare affirme que son analyse de la télémétrie disponible n’a révélé aucune activité suspecte ou malveillante en dehors des tests autorisés menés par ses chercheurs et ingénieurs.