A Cloudflare corrigiu uma vulnerabilidade de exposição de dados entre clientes (cross-tenant) em seu produto Containers que permitia que um cliente de uma conta Workers Paid recuperasse dados residuais de disco deixados por cargas de trabalho de outros clientes no mesmo host compartilhado. O post-mortem da empresa, publicado em seu blog, afirma que a falha foi reportada pelo pesquisador de segurança Oren Yomtov, da Accomplish, por meio do programa de bug bounty da Cloudflare em 4 de setembro de 2026, e que a Cloudflare não encontrou evidências de que a técnica tenha sido explorada por alguém fora da pesquisa autorizada.

A causa raiz está na camada de armazenamento, não no runtime do container em si. O Cloudflare Containers executa cada carga de trabalho dentro de uma máquina virtual dedicada, alimentada pelo monitor de máquina virtual Firecracker, com um disco raiz gravável baseado no thin provisioning do Linux device mapper, ou dm-thin, apresentado ao guest como /dev/vdc. Os pools de armazenamento afetados usavam um tamanho de thin-block de 64 KiB e estavam configurados com a opção skip_block_zeroing, que instrui o dm-thin a pular a limpeza de blocos recém-alocados antes de entregá-los a um container. Quando um volume thin era excluído, seus blocos físicos retornavam a um pool compartilhado entre múltiplas contas de clientes — e quando um desses blocos era posteriormente reatribuído, apenas a parte que um novo container efetivamente escrevia era sobrescrita. O restante ainda podia conter bytes de um cliente anterior.

A prova de conceito, como descrita no post da Cloudflare, explorou essa brecha diretamente: criar um container, abrir o disco raiz bruto (raw), identificar regiões alinhadas a 64 KiB correspondentes a espaço livre no sistema de arquivos ext4 do guest, e escrever um único bloco de 4 KiB em cada uma delas. Essa pequena escrita era suficiente para acionar a alocação, pelo dm-thin, do bloco completo de 64 KiB a partir do pool compartilhado; uma leitura raw subsequente dos 60 KiB não sobrescritos podia então revelar dados deixados pelo cliente anterior daquele bloco. Para confirmar que o material recuperado realmente pertencia a outros clientes e não ao próprio sistema de arquivos de teste, os pesquisadores usaram checksums de blocos de diretório do ext4 — uma técnica que, segundo o post da Cloudflare, eles validaram testando primeiro contra 162 blocos que haviam deliberadamente criado e excluído eles mesmos, atribuindo corretamente todos os 162 de volta ao próprio sistema de arquivos.

A escala do que os pesquisadores efetivamente recuperaram é o número que deveria preocupar qualquer um que opere infraestrutura de container compartilhada: em seis placements de produção, o post-mortem da Cloudflare relata que a equipe examinou 5,614 blocos de diretório testáveis e identificou 2,700 inodes de diretório distintos e alheios por meio de análise de checksum — nenhum dos quais pertencia ao próprio sistema de arquivos de teste. Material residual apareceu em 18 de 24 placements e 20 de 22 nós subjacentes distribuídos por quatro continentes, incluindo estruturas de diretório, páginas de banco de dados e, segundo o post, "bancos de dados SQLite estruturalmente completos". A Cloudflare afirma que os materiais a ela submetidos não continham valores de conteúdo recuperado, nomes de arquivo, credenciais ou identificadores de terceiros, e que os pesquisadores confirmaram ter excluído com segurança os dados recuperados após a submissão.

A correção da Cloudflare teve duas partes, e a segunda é a que mostra o quão difícil é fechar completamente essa classe de bug. A mitigação imediata foi remover o skip_block_zeroing da configuração do pool dm-thin em toda a frota, restaurando a limpeza padrão de blocos recém-alocados — uma mudança que os pesquisadores confirmaram de forma independente ter quebrado sua prova de conceito. Mas zerar as novas alocações não higienizava blocos já mapeados em discos de containers em execução, nem os que estavam em cache nos snapshots dm-thin preparados de cada host para as camadas de imagem OCI, já que um novo container podia herdar esses mapeamentos em cache sem acionar uma nova alocação. A Cloudflare afirma que precisou aposentar todos os discos de containers em execução e limpar o cache de imagens de cada host, drenando hosts durante horários de baixo movimento e reiniciando VMs para forçar a recriação de discos e camadas em cache com alocações zeradas — uma limpeza que, segundo a empresa, foi concluída em toda a frota até 19 de setembro.

Os limites da exploração importam tanto quanto seu alcance: o post da Cloudflare é explícito ao afirmar que a técnica não podia mirar um cliente, carga de trabalho, host ou dado específico, que a presença de dados residuais não era garantida, e que os pesquisadores não demonstraram nenhuma modificação de dados ativos de outro cliente nem impacto na disponibilidade das cargas de trabalho. A Cloudflare afirma que sua revisão da telemetria histórica de I/O de disco, usando assinaturas de detecção construídas a partir do padrão de leitura/escrita da técnica reportada, encontrou atividade atribuível apenas aos pesquisadores e a engenheiros da Cloudflare conduzindo validação autorizada.

A linha do tempo é a parte que vale a pena copiar para um runbook de resposta a incidentes: relato às 15:26 UTC em 4 de setembro, incidente aberto às 18:45, correção do runtime mesclada até as 21:27 do mesmo dia, implantação em toda a frota concluída em 7 de setembro, limpeza completa dos snapshots em cache finalizada em 19 de setembro. Para qualquer equipe que opere infraestrutura de container multi-tenant para cargas de trabalho de IA, a lição não é apenas "verifique os padrões de zeragem do seu pool de armazenamento" — é que uma limpeza de host compartilhado após uma correção na camada de armazenamento precisa levar em conta cada camada de cache que possa ter herdado o estado anterior à mitigação, não apenas a correção ativa em si.