Le 24 septembre 2026, Cloudflare a détaillé une vulnérabilité de Containers et Sandboxes signalée le 4 septembre par le chercheur Oren Yomtov. Un client Workers Paid pouvait récupérer des blocs de stockage résiduels d’un autre workload placé sur le même hôte.
Ce que Cloudflare a corrigé
Le problème venait de la réutilisation de blocs thin-provisioned dans un pool partagé. Lorsque skip_block_zeroing était actif, un bloc réattribué pouvait conserver une portion de ses anciennes données si le nouveau workload n’écrivait pas toute la zone.
Cloudflare indique avoir corrigé le runtime, déployé la correction sur la flotte et nettoyé les anciens snapshots. L’entreprise dit n’avoir observé aucune exploitation malveillante au-delà des tests autorisés.
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.
Ces limites n’annulent pas le problème : elles permettent de décrire honnêtement le risque sans affirmer que les données de tous les clients ont été exposées.
Les données à inventorier
Les équipes utilisant Containers ou Sandboxes doivent recenser les secrets, jetons, fichiers de configuration et données temporaires présents dans les workloads avant le déploiement de la correction. Portez une attention particulière aux variables d’environnement et aux bases SQLite temporaires.
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.
