A Cloudflare corrigiu uma vulnerabilidade entre inquilinos nos serviços Cloudflare Containers e Cloudflare Sandboxes, depois que pesquisadores da equipe Accomplish demonstraram que um usuário com uma conta Workers Paid poderia recuperar partes remanescentes de blocos de armazenamento usados anteriormente por contêineres de outros clientes no mesmo host. O pesquisador Oren Yomtov informou o problema à empresa em 4 de setembro de 2026 por meio do programa de recompensas por vulnerabilidades, e a Cloudflare afirma não ter encontrado evidências de comprometimento de dados de clientes.
Como o problema surgiu?
O Containers usa a tecnologia Linux device mapper thin provisioning para fornecer um disco raiz gravável dentro de uma máquina virtual executada pelo Firecracker. Os pools de armazenamento afetados usavam blocos de 64 quilobytes com a opção skip_block_zeroing ativada, o que significava que os blocos realocados não eram zerados antes de serem disponibilizados a um novo contêiner.
Ao escrever apenas 4 quilobytes em parte de um novo bloco, os 60 quilobytes restantes podiam conservar dados do proprietário anterior. Uma leitura posterior do dispositivo bruto /dev/vdc poderia revelar esses bytes, embora o novo contêiner nunca os tivesse escrito.
O que o teste comprovou?
A exploração não permitia escolher um cliente, contêiner ou host específico, e a aparição dos restos de dados não era garantida. Ainda assim, os pesquisadores relataram ter detectado material remanescente em 18 dos 24 locais testados e em 20 das 22 máquinas principais em quatro continentes. Os tipos observados incluíam estruturas de diretórios, páginas de bancos de dados e bancos SQLite estruturalmente completos.
Os pesquisadores usaram hashes e metadados do sistema de arquivos ext4 para distinguir os blocos de seu sistema experimental dos blocos provenientes de outros sistemas de arquivos. De acordo com os resultados publicados, foram identificados 2.700 nós de diretórios estrangeiros, enquanto nenhum dos 5.614 blocos de diretórios de teste foi atribuído ao sistema dos pesquisadores. A Cloudflare afirma que os materiais apresentados a ela não incluíam nomes de arquivos, identificadores, credenciais ou conteúdo recuperado, e que os pesquisadores apagaram com segurança os dados que tinham em sua posse.
Como a Cloudflare corrigiu a falha?
A empresa removeu a opção skip_block_zeroing das configurações dos pools dm-thin, fazendo com que os novos blocos voltassem ao comportamento padrão de serem zerados antes de serem disponibilizados. Os pesquisadores confirmaram de forma independente que a prova de conceito deixou de funcionar após essa alteração.
No entanto, zerar as novas alocações não era suficiente, porque alguns blocos ainda estavam associados a discos de contêineres existentes ou a snapshots temporários de camadas de imagens OCI. Por isso, a Cloudflare desativou os discos antigos dos contêineres, removeu os snapshots armazenados em cache antes da correção, esvaziou os hosts, reiniciou as máquinas virtuais e limpou o cache de imagens. Essa limpeza foi concluída em 19 de setembro de 2026, enquanto a implantação da correção principal foi concluída em 7 de setembro.
Por que esta notícia é importante?
A importância do incidente está em mostrar que o isolamento entre inquilinos na infraestrutura de nuvem não depende apenas das máquinas virtuais; detalhes da reutilização do armazenamento e do comportamento do thin provisioning podem abrir um canal para o vazamento de dados inativos. Por outro lado, as limitações práticas eram claras: o teste não conseguiu atingir uma vítima específica nem acessar um disco efetivamente conectado, e não demonstrou a modificação de dados de outro cliente ou o impacto na disponibilidade de suas cargas de trabalho.
A Cloudflare revisou registros históricos de medição de entrada e saída de discos em busca de um padrão distinto que combinasse escritas de 4 quilobytes com leituras maiores. Ela atribuiu a atividade compatível com esse padrão aos pesquisadores e aos seus engenheiros durante a validação autorizada, e não encontrou atividade adicional que indicasse a exploração do ataque por outra parte. Segundo a empresa, os clientes da Cloudflare não precisam tomar nenhuma medida em razão da correção.