Le 24 septembre 2026, Cloudflare et le chercheur Oren Yomtov ont détaillé une vulnérabilité de Cloudflare Containers et Sandboxes signalée le 4 septembre. Oren Yomtov précise que Browser Run utilisait la même implémentation de disque et était également concerné. Un client Workers Paid pouvait récupérer certains blocs de stockage résiduels d’un workload antérieur placé sur le même hôte. La remédiation du parc, y compris le retrait des anciens disques et snapshots concernés, a été achevée le 19 septembre.
Ce que Cloudflare a corrigé
Le problème venait de la réutilisation de blocs de 64 Kio dans un pool partagé. Lorsque skip_block_zeroing était actif, une écriture partielle de 4 Kio sur un bloc réattribué pouvait laisser les 60 Kio restants contenir des données de l’ancien workload, accessibles par lecture brute du disque du nouveau conteneur.
Cloudflare indique avoir supprimé skip_block_zeroing, puis retiré les disques de conteneurs existants et nettoyé les snapshots d’images antérieurs à la correction. L’entreprise a annoncé la fin de cet assainissement le 19 septembre. Son analyse de la télémétrie historique n’a trouvé que les tests autorisés des chercheurs et de ses équipes, sans indice d’exploitation malveillante par un tiers.
Un scénario précis, pas une fuite générale
Le scénario nécessitait un compte Workers Paid et une capacité à obtenir un placement favorable. Les chercheurs ne pouvaient pas choisir une victime, un workload ou un hôte précis, et la présence de données résiduelles n’était pas garantie.
Les chercheurs ont observé des résidus sur 18 des 24 placements de production testés, mais la récupération dépendait du placement et des blocs réattribués. Ils ne pouvaient pas sélectionner une victime, un workload ou un hôte, ni lire un disque activement attaché. Cloudflare n’a trouvé aucun signe que le vecteur ait été exploité par un acteur malveillant. Ces limites évitent de confondre exposition possible et fuite générale confirmée.
Les données à inventorier
Cloudflare indique qu’aucune action de configuration n’est requise côté client. Pour documenter les accès sensibles et organiser leur rotation si un autre indice d’exposition existe, consultez notre guide du partage des mots de passe en équipe et notre guide de politique de mots de passe pour PME. Portez une attention particulière aux secrets, jetons, variables d’environnement et fichiers temporaires qui se trouvaient dans les workloads concernés.
La correction Cloudflare réduit le risque côté infrastructure. Elle ne permet pas de conclure que chaque secret stocké dans un workload est resté confidentiel si un indice contraire existe.
Après une exposition possible
Si un workload contenait un secret sensible et que l’organisation ne peut pas exclure une lecture, préparez sa rotation, examinez les journaux et conservez les éléments utiles. Ne remplacez pas une clé simplement pour effacer une trace : coordonnez la rotation avec l’analyse.
Évitez aussi de copier des secrets dans des tickets ou des notes d’incident. Le registre de remédiation doit décrire l’objet et l’action sans reproduire la valeur secrète.
Le lien avec Soclyde
Soclyde ne corrige pas Cloudflare Containers et ne peut pas vérifier l’historique d’un workload. Il peut aider à conserver des secrets distincts dans un coffre chiffré local-first et à retrouver ceux à faire tourner après une analyse.
Cette approche limite les copies centralisées des accès, sans transformer le coffre en preuve d’intégrité de l’infrastructure cloud.
À retenir
Cloudflare a corrigé une faille d’isolation pouvant exposer des blocs résiduels, sans preuve annoncée d’exploitation malveillante. Inventoriez les secrets des workloads et préparez leur rotation si nécessaire. Consultez le générateur de mots de passe sécurisé ou contactez Soclyde.
