Uma falha de segurança no Cloudflare Containers comprometeu uma das principais garantias de ambientes de nuvem compartilhados: o isolamento entre clientes. O problema permitia que um contêiner acessasse dados residuais deixados no armazenamento por outro cliente que havia utilizado anteriormente o mesmo servidor físico.
A vulnerabilidade estava relacionada ao armazenamento compartilhado usado pela infraestrutura de Containers e Sandboxes da Cloudflare. Um erro na forma como blocos físicos eram reutilizados permitia que parte do conteúdo anterior permanecesse disponível para um novo workload. Em determinadas condições, uma gravação de apenas 4 KiB poderia deixar outros 60 KiB de dados antigos acessíveis.
O caso é particularmente relevante para desenvolvedores, sysadmins e profissionais de DevOps porque demonstra que o isolamento entre locatários não depende apenas da separação dos processos ou das máquinas virtuais. A camada de armazenamento também precisa impedir qualquer reutilização insegura de dados entre clientes.
Como funcionava a vulnerabilidade no Cloudflare Containers
O Cloudflare Containers permite executar workloads isolados na infraestrutura da Cloudflare. A plataforma utiliza máquinas virtuais baseadas em Firecracker, com cada workload recebendo um disco raiz gravável apresentado ao sistema convidado.
Por trás desse armazenamento estava o mecanismo Linux device-mapper thin provisioning, conhecido como dm-thin. Essa tecnologia permite administrar volumes de maneira eficiente, utilizando um pool de armazenamento físico compartilhado e atribuindo blocos conforme os workloads precisam deles.
Em uma infraestrutura multi-tenant, entretanto, existe uma exigência fundamental: quando um bloco utilizado por um cliente volta para o pool, seu conteúdo anterior não pode ficar disponível para o próximo cliente.
Foi justamente nesse ponto que surgiu o problema.
Os pools utilizados pela infraestrutura afetada empregavam blocos físicos de 64 KiB. A configuração skip_block_zeroing fazia com que o sistema não zerasse automaticamente esses blocos antes de sua reutilização.
Na prática, isso significava que um bloco devolvido ao pool poderia continuar contendo informações pertencentes ao workload anterior. Se posteriormente fosse atribuído a outro cliente e utilizado parcialmente, parte do conteúdo antigo poderia permanecer legível.
O detalhe dos 4 KiB e 64 KiB
O comportamento fica mais claro ao observar a diferença entre o tamanho da gravação e o tamanho do bloco físico.
Imagine que um cliente utilize um bloco de 64 KiB e grave nele dados de sua aplicação. Quando esse volume é removido, o bloco físico retorna ao pool compartilhado.
Posteriormente, outro cliente recebe esse mesmo bloco. Seu sistema de arquivos pode realizar uma gravação de apenas 4 KiB.
Como o mecanismo de zeragem estava desativado, somente os 4 KiB gravados pelo novo cliente substituíam o conteúdo anterior. Os 60 KiB restantes poderiam continuar contendo dados do cliente anterior.
O pesquisador utilizou justamente esse comportamento para demonstrar a exposição.
A sequência podia ser resumida da seguinte maneira:
Cliente A grava dados → volume é removido → bloco retorna ao pool → Cliente B recebe o bloco → Cliente B grava 4 KiB → até 60 KiB anteriores permanecem → Cliente B consegue recuperar dados residuais.
Esse mecanismo não significava que qualquer contêiner pudesse simplesmente acessar todo o armazenamento de outro cliente. A exploração dependia da reutilização dos blocos físicos e do posicionamento adequado das gravações.
Ainda assim, a possibilidade de recuperar dados de outro locatário representa uma quebra importante do modelo de isolamento esperado em uma plataforma de nuvem.
Que informações poderiam aparecer nos blocos residuais?
O problema ocorria no nível do armazenamento, e não estava limitado a um tipo específico de arquivo.
Dependendo de quais dados estivessem armazenados nos blocos reutilizados, poderiam aparecer fragmentos de arquivos, estruturas de sistemas de arquivos, páginas de bancos de dados e dados temporários de aplicações.
Entre os exemplos identificados durante a investigação estavam informações relacionadas a bancos SQLite, arquivos .env e perfis do Chromium.
O risco dos arquivos .env merece atenção especial. Em aplicações modernas, esses arquivos frequentemente armazenam tokens, credenciais, chaves de API, strings de conexão e outros segredos operacionais.
Da mesma forma, bancos SQLite podem conter informações estruturadas de aplicações, enquanto perfis de navegadores podem armazenar configurações e outros dados relacionados ao ambiente executado.
Isso não significa que todos esses dados tenham sido efetivamente acessados por terceiros. A Cloudflare informou que sua investigação não encontrou evidências de exploração maliciosa da vulnerabilidade.
O ponto central é que a falha criava uma condição na qual dados residuais de outro cliente poderiam, em determinadas circunstâncias, ser expostos.
Como os pesquisadores descobriram o problema
A vulnerabilidade foi descoberta pelo pesquisador Oren Yomtov, da Accomplish, durante uma investigação conduzida por meio do programa de bug bounty da Cloudflare.
O problema foi reportado em 4 de setembro de 2026. Os testes demonstraram que era possível provocar a reutilização de blocos e observar dados que haviam sido deixados por workloads anteriores.
A investigação também mostrou que o comportamento não estava limitado a uma única instância. Testes realizados em diferentes posicionamentos da infraestrutura encontraram dados residuais em múltiplos nós.
O pesquisador utilizou gravações alinhadas de 4 KiB em regiões específicas do armazenamento para provocar a alocação de blocos físicos de 64 KiB. Como a configuração não exigia a zeragem completa antes da reutilização, os bytes restantes podiam preservar conteúdo anterior.
A Cloudflare reproduziu internamente o comportamento e identificou a configuração do dm-thin como a causa do problema.
Como a Cloudflare corrigiu a vulnerabilidade
A primeira etapa da correção foi remover a configuração skip_block_zeroing dos pools de armazenamento utilizados pelo Containers.
Com a alteração, os blocos passaram a ser zerados antes de serem reutilizados, eliminando o mecanismo que permitia que dados antigos permanecessem acessíveis.
Entretanto, corrigir a configuração não era suficiente para eliminar todos os dados potencialmente residuais que já existiam.
Alguns discos criados antes da correção poderiam conter mapeamentos associados ao comportamento anterior. Além disso, a infraestrutura mantinha snapshots de camadas de imagens OCI em cache, que também precisavam ser tratados.
Por isso, a Cloudflare adotou medidas adicionais, incluindo a remoção e recriação de discos afetados, limpeza de snapshots antigos e drenagem de hosts para permitir a reinicialização das máquinas virtuais e a limpeza dos caches.
A implantação da correção começou em 4 de setembro de 2026. Segundo a Cloudflare, a mitigação foi concluída em toda a frota em 7 de setembro, enquanto a limpeza dos snapshots anteriores à correção terminou em 19 de setembro de 2026.
A empresa também criou mecanismos de detecção para procurar padrões de operações de entrada e saída associados à técnica utilizada na pesquisa.
De acordo com a investigação divulgada pela Cloudflare, foram identificadas atividades relacionadas aos próprios pesquisadores e aos engenheiros que trabalhavam na validação da vulnerabilidade. Não foram encontradas evidências de exploração por terceiros nem de comprometimento de dados de clientes.
O que a vulnerabilidade revela sobre segurança multi-tenant
O caso demonstra que o isolamento em ambientes de nuvem precisa ser analisado muito além da camada de contêineres.
Uma arquitetura pode utilizar máquinas virtuais, Firecracker, namespaces, controles de acesso e isolamento de processos, mas ainda apresentar riscos caso o armazenamento físico compartilhado não seja devidamente sanitizado.
O thin provisioning é importante para aumentar a eficiência da infraestrutura, mas sua utilização exige mecanismos capazes de impedir que blocos anteriormente utilizados sejam entregues a outro cliente contendo informações antigas.
Para equipes de infraestrutura e segurança, isso reforça a necessidade de avaliar todo o ciclo de vida dos dados: criação, gravação, exclusão, reutilização e sanitização.
Também existe uma lição importante sobre otimizações de desempenho. Alterações que reduzem operações de armazenamento podem parecer vantajosas isoladamente, mas precisam ser avaliadas considerando as garantias de segurança oferecidas pela plataforma.
No caso do Cloudflare Containers, a configuração responsável pelo problema tinha uma função legítima relacionada ao gerenciamento dos blocos, mas acabou criando uma condição incompatível com o nível de isolamento esperado em uma infraestrutura multi-tenant.
Uma lição para ambientes de nuvem e containers
A vulnerabilidade corrigida pela Cloudflare mostra que excluir um arquivo ou destruir um volume lógico não significa necessariamente que os dados deixaram de existir imediatamente no armazenamento físico.
Quando a infraestrutura reutiliza recursos entre diferentes clientes, os mecanismos responsáveis por essa reutilização precisam garantir que nenhum conteúdo anterior possa ser recuperado pelo próximo workload.
Esse princípio vale para containers, máquinas virtuais, ambientes serverless, plataformas de desenvolvimento e serviços de armazenamento compartilhado.
Para administradores e equipes de DevOps, o episódio também reforça a importância de verificar como o provedor escolhido trata blocos reutilizados, volumes temporários, snapshots, caches e descarte seguro de dados.
A correção aplicada pela Cloudflare eliminou o mecanismo demonstrado pelos pesquisadores e incluiu medidas adicionais para remover possíveis resíduos da configuração anterior. O episódio, portanto, serve como um exemplo concreto de como uma falha aparentemente localizada na camada de armazenamento pode afetar uma propriedade fundamental de uma plataforma de nuvem: garantir que um cliente não consiga acessar dados pertencentes a outro.
Para quem trabalha com Linux, containers, DevOps ou segurança em nuvem, o caso merece atenção justamente por mostrar que o isolamento multi-tenant depende da interação entre diversas camadas da infraestrutura.
