Cloudflare a corrigé une vulnérabilité inter-locataires dans les services Cloudflare Containers et Cloudflare Sandboxes, après que des chercheurs de l’équipe Accomplish eurent démontré qu’un utilisateur disposant d’un compte Workers Paid pouvait récupérer des fragments résiduels de blocs de stockage utilisés auparavant par les conteneurs d’autres clients sur le même hôte. Le chercheur Oren Yomtov a signalé le problème à l’entreprise le 4 septembre 2026 par l’intermédiaire du programme de primes aux bogues, et Cloudflare affirme n’avoir trouvé aucune preuve d’une compromission des données clients.
Comment le problème est-il apparu ?
Containers s’appuie sur la technologie Linux device mapper thin provisioning pour fournir un disque racine inscriptible dans une machine virtuelle fonctionnant via Firecracker. Les pools de stockage concernés utilisaient des blocs de 64 kilo-octets avec l’option skip_block_zeroing activée, ce qui signifiait que les blocs réattribués n’étaient pas remis à zéro avant d’être mis à la disposition d’un nouveau conteneur.
Lors de l’écriture de seulement 4 kilo-octets dans une partie d’un nouveau bloc, la partie restante de 60 kilo-octets pouvait conserver des données de l’ancien propriétaire. Une lecture ultérieure depuis le périphérique brut /dev/vdc pouvait révéler ces octets, même si le nouveau conteneur ne les avait jamais écrits.
Qu’est-ce que le test a démontré ?
L’exploitation ne permettait pas de sélectionner un client, un conteneur ou un hôte précis, et l’apparition de résidus de données n’était pas garantie. Néanmoins, les chercheurs ont indiqué avoir détecté des données résiduelles dans 18 des 24 emplacements testés, ainsi que sur 20 des 22 nœuds principaux répartis sur quatre continents. Les types observés comprenaient des structures de répertoires, des pages de bases de données et des bases SQLite structurellement complètes.
Les chercheurs ont utilisé des tests de hachage et des métadonnées du système de fichiers ext4 pour distinguer les blocs de leur système expérimental des blocs provenant d’autres systèmes de fichiers. Selon les résultats publiés, 2 700 nœuds de répertoires étrangers ont été identifiés, tandis qu’aucun des 5 614 blocs de répertoires de test n’a été attribué au système des chercheurs. Cloudflare affirme que les éléments qui lui ont été fournis ne comprenaient ni noms de fichiers, ni identifiants, ni identifiants d’authentification, ni contenu récupéré, et que les chercheurs ont supprimé en toute sécurité les données qu’ils détenaient.
Comment Cloudflare a-t-elle corrigé la faille ?
L’entreprise a supprimé l’option skip_block_zeroing des paramètres des pools dm-thin, rétablissant ainsi le comportement par défaut qui remet les nouveaux blocs à zéro avant leur mise à disposition. Les chercheurs ont confirmé indépendamment que la preuve de concept ne fonctionnait plus après cette modification.
Mais la remise à zéro des nouvelles allocations ne suffisait pas, car certains blocs restaient associés à des disques de conteneurs existants ou à des instantanés temporaires de couches d’images OCI. Cloudflare a donc désactivé les anciens disques de conteneurs, supprimé les instantanés mis en cache avant la correction, vidé les hôtes, redémarré les machines virtuelles et nettoyé le cache d’images. Ce nettoyage s’est achevé le 19 septembre 2026, tandis que le déploiement de la correction principale avait été terminé le 7 septembre.
Pourquoi cette actualité est-elle importante ?
L’importance de cet incident tient au fait qu’il montre que l’isolation des locataires dans l’infrastructure cloud ne repose pas uniquement sur les machines virtuelles : les détails de la réutilisation du stockage et du comportement du provisionnement léger peuvent ouvrir un canal de fuite de données inactives. En revanche, les limites pratiques étaient claires : le test ne permettait pas de cibler une victime précise ni d’accéder à un disque effectivement connecté, et il n’a pas été démontré qu’il était possible de modifier les données d’un autre client ou d’affecter la disponibilité de ses charges de travail.
Cloudflare a examiné les journaux historiques de mesure des entrées-sorties des disques à la recherche d’un schéma distinctif combinant des écritures de 4 kilo-octets et des lectures plus importantes. Elle a attribué l’activité correspondant à ce schéma aux chercheurs et à ses ingénieurs pendant la vérification autorisée, et n’a trouvé aucune activité supplémentaire indiquant une exploitation de l’attaque par une autre partie. Selon l’entreprise, aucune action n’est requise de la part des clients de Cloudflare.