Cybersecurite
Cloudflare répare une fuite de données dans Containers
Une vulnérabilité dans Cloudflare Containers exposait des données résiduelles entre clients partageant un même serveur physique. Découverte par Accomplish début septembre 2026, l'anomalie de stockage a été corrigée sans exiger d'intervention des utilisateurs.
Par Tao · rédaction IA
Le 4 septembre 2026, Oren Yomtov de la société Accomplish a signalé à Cloudflare via HackerOne une faille d'isolation permettant de lire des blocs de stockage non purgés issus d'autres conteneurs sur une même machine hôte.
Le correctif déployé par Cloudflare rétablit l'isolation stricte des disques sans imposer de migration aux abonnés Workers Paid. Les entreprises utilisant ces environnements partagés évitent ainsi l'exposition passive de leurs fichiers et identifiants.
Un défaut d'allocation exposait des fragments de disques
Cloudflare Containers permet d'exécuter des applications conteneurisées adossées à Cloudflare Workers, sous la supervision du moniteur Firecracker. Chaque conteneur dispose d'un disque racine géré via le mécanisme Linux dm-thin, qui alloue l'espace par blocs de 64 KiB. Selon la documentation publiée sur le blog de Cloudflare, les volumes libérés retournaient dans un pool commun avec l'option skip_block_zeroing activée. Cette configuration empêchait la réinitialisation des blocs avant réattribution. Dès lors, lorsqu'un conteneur effectuait une écriture partielle de 4 KiB dans un espace non initialisé, le système lui affectait un bloc complet sans en effacer les 60 KiB résiduels. Ce mécanisme laissait des informations issues d'anciens locataires directement lisibles par un simple accès direct au périphérique de stockage invité.
La preuve de concept a extrait des bases complètes
Pour valider l'existence de la brèche, le chercheur Oren Yomtov de la firme Accomplish a élaboré une méthode ciblée sur le système de fichiers ext4. En écrivant des blocs alignés de 4 KiB sur l'espace libre de son propre conteneur, son script a forcé le système à lui attribuer des blocs physiques réutilisés. L'analyse des sommes de contrôle de métadonnées a révélé 2 700 nœuds d'index de répertoires étrangers sur 5 614 blocs examinés. Les tests menés ont mis au jour des résidus sur 18 des 24 déploiements évalués et sur 20 des 22 nœuds sous-jacents audités. Les éléments détectés comprenaient des profils Chromium, des fichiers de configuration, des fragments de bases de données et des fichiers SQLite complets, sans que le chercheur ne perturbe l'activité des autres clients.
Cloudflare a purgé l'ensemble de ses disques physiques
Dès la confirmation du problème le 4 septembre, l'équipe technique de l'infrastructure a retiré le paramètre skip_block_zeroing afin d'imposer la mise à zéro systématique des nouveaux blocs alloués. Selon le compte-rendu relayé par BleepingComputer, cette première modification ne suffisait pas à assainir les volumes déjà montés ni les instantanés d'images OCI conservés en cache. Les équipes ont donc programmé le retrait de tous les disques de conteneurs en cours d'exécution et le redémarrage des machines virtuelles durant les heures creuses. L'opération globale de nettoyage, achevée le 19 septembre 2026, a supprimé l'ensemble des couches d'images historiques pour garantir que chaque conteneur actif repose désormais exclusivement sur des blocs vierges.
Le correctif élimine les risques sans action client
La télémétrie historique examinée par Cloudflare confirme qu'aucun acteur malveillant n'a exploité ce vecteur d'attaque avant son signalement. Les seules traces d'activité correspondant à ce schéma d'entrées et sorties provenaient des tests autorisés menés par Accomplish et des vérifications internes. Les clients n'ont aucune manipulation technique à opérer sur leurs déploiements existants, l'intégralité du correctif ayant été appliquée au niveau de l'infrastructure mutualisée de l'hébergeur. Les entreprises conservent toutefois la responsabilité d'appliquer les principes d'hygiène élémentaires, notamment le chiffrement des données sensibles avant leur écriture sur disque et la rotation régulière des secrets applicatifs pour neutraliser tout risque d'exposition résiduelle sur des environnements cloud partagés.
- 2 700 nœuds d'index de répertoires étrangers identifiés par analyse de sommes de contrôle blog.cloudflare.com, 2026-09-04
Une exploitation réussie aurait franchi la frontière d'isolation entre locataires et aurait pu divulguer des métadonnées du système de fichiers, des structures de répertoires, des pages de bases de données et des données applicatives.
Bien que la fuite ait été comblée sans fuite avérée vers des tiers malveillants, l'attaque démontre qu'une simple option d'optimisation de stockage peut anéantir l'étanchéité promise par l'isolation logicielle.
Pour un professionnel ou une petite structure exploitant Cloudflare Containers, aucune modification de code ni intervention technique n'est requise cette semaine, l'assainissement ayant été finalisé le 19 septembre 2026.
Deviez-vous modifier la configuration de vos conteneurs Cloudflare ?
Non. Le déploiement du correctif et la purge des instantanés ont été entièrement réalisés côté infrastructure par Cloudflare sans intervention client requise.
Un attaquant pouvait-il cibler spécifiquement vos données ?
Non. L'exploitation dépendait du hasard de l'attribution des blocs de stockage réutilisés sur un même serveur hôte, sans ciblage possible.
- Une mauvaise configuration de dm-thin omettait l'effacement de blocs réutilisés de 64 KiB.
- Le chercheur d'Accomplish a identifié des artefacts résiduels sur 20 nœuds hôtes testés sur 22.
- L'infrastructure a été totalement assainie au 19 septembre 2026 sans action requise des clients.