Cloudflare corrige vulnerabilidade de exposição de dados entre tenants no Containers

Em 4 de setembro de 2026, a Cloudflare recebeu, por meio do programa de bug bounty, um relato de Oren Yomtov, pesquisador da Accomplish, sobre exposição de dados entre tenants no Cloudflare Containers e no Cloudflare Sandboxes. A empresa afirma que a correção foi aplicada em toda a frota e que não há evidência de comprometimento de dados de clientes. A atividade atribuível à técnica, segundo a telemetria histórica de I/O de disco, veio apenas dos pesquisadores e de engenheiros da Cloudflare em validação autorizada, conforme a análise publicada.

Como o dm-thin abriu a brecha

Cada container roda em uma VM dedicada com Firecracker e recebe um root disk gravável apresentado como /dev/vdc. O armazenamento usa Linux device mapper thin provisioning (dm-thin): blocos físicos só são alocados quando uma região não mapeada é gravada. Nos pools afetados, o bloco thin tinha 64 KiB. Quando o volume de um container era removido, seus blocos voltavam ao pool compartilhado por workloads de múltiplas contas.

O problema vinha da opção skip_block_zeroing. Com ela, o dm-thin deixava de zerar blocos recém-alocados antes de entregá-los. Uma escrita menor que o bloco — 4 KiB, no PoC — forçava a alocação de um bloco de 64 KiB, mas substituía apenas a parte gravada. Os 60 KiB restantes podiam manter dados do container anterior. Ler uma região não mapeada de um disco novo, por outro lado, devolvia zeros sem alocar bloco físico.

O PoC e os números da validação

O teste seguia cinco passos: criar um container com conta Workers Paid; abrir /dev/vdc; registrar uma baseline; gravar um bloco de 4 KiB em cada região de 64 KiB alinhada correspondente a espaço livre no filesystem ext4 do guest; reler o disco e examinar as porções não sobrescritas. A submissão continha contagens, offsets, tamanhos, resultados de checksum e prefixos de hash truncados, mas não incluía nomes de arquivo, credenciais, hostnames, endereços ou valores de conteúdo de terceiros.

Para distinguir blocos próprios de blocos estrangeiros, os pesquisadores usaram checksums de blocos de diretório do ext4 com metadata_csum. Em seis colocações de produção, zero dos 5.614 blocos de diretório testáveis foi atribuído ao filesystem dos pesquisadores; foram identificados 2.700 inodes de diretório estrangeiros distintos. O método foi validado contra 162 blocos criados e deletados no filesystem de teste, com atribuição correta de todos eles. Material residual apareceu em 18 de 24 colocações e em 20 de 22 nós em quatro continentes, incluindo estruturas de diretório, páginas de banco de dados e bancos SQLite estruturalmente completos.

Mitigação e limites

A primeira correção foi remover a opção skip_block_zeroing dos pools dm-thin em toda a frota, restaurando o zeroing padrão de blocos recém-alocados. A Cloudflare afirma que o PoC deixou de funcionar após a mudança, com confirmação independente dos pesquisadores. Nenhuma mudança de configuração foi exigida dos clientes.

A postagem registra uma limitação importante: zerar novas alocações não sanitiza blocos já mapeados em thin devices existentes. Além disso, a técnica não permitia escolher vítima, workload, host ou dado específico, nem acessar um disco ativamente anexado; a exposição dependia do placement e dos blocos liberados reatribuídos pelo dm-thin. Embora a Cloudflare não tenha encontrado evidência de exploração maliciosa, a ausência de evidência é uma ressalva típica desse tipo de investigação. Para times de plataforma, o caso reforça a auditoria de opções de pool que desativam zeroing em infraestrutura multi-tenant. O relato completo está na postagem oficial.