Uma falha de segurança no Cloudflare Containers permitia que dados deixados por contêineres antigos fossem recuperados por novos workloads executados no mesmo servidor. O problema estava relacionado ao thin provisioning do Linux, que reutilizava blocos de armazenamento de 64 KiB sem garantir que seu conteúdo anterior tivesse sido apagado.
Na prática, um cliente poderia receber um bloco físico que havia sido utilizado anteriormente por outro workload. Ao gravar apenas uma parte desse bloco, os dados antigos que permaneciam no restante do espaço poderiam ser recuperados por meio de leituras de baixo nível. A descoberta foi feita pelo pesquisador Oren Yomtov, da Accomplish, e reportada à Cloudflare em setembro de 2026.
O episódio chama atenção para um aspecto menos evidente da segurança em ambientes de nuvem: o isolamento entre clientes também depende da forma como o armazenamento físico é reutilizado. Mesmo quando contêineres e máquinas virtuais estão corretamente isolados, dados residuais em blocos compartilhados podem criar uma fronteira de segurança inesperada.
Como a falha no Cloudflare Containers expunha dados residuais
O Cloudflare Containers permite executar contêineres em infraestrutura gerenciada pela Cloudflare. Para fornecer armazenamento aos workloads, a plataforma utilizava thin provisioning por meio do device-mapper do Linux, uma tecnologia que permite administrar grandes pools de armazenamento e distribuir espaço conforme a necessidade.
Nesse modelo, o espaço virtual apresentado ao contêiner não precisa corresponder imediatamente a uma região física exclusiva do disco. Os blocos físicos são atribuídos conforme são utilizados e podem retornar ao pool quando deixam de ser necessários.
A configuração problemática envolvia blocos de 64 KiB e a opção skip_block_zeroing. Com esse recurso habilitado, um bloco físico que voltava ao pool podia ser entregue a outro volume sem passar pelo processo de zeramento automático.
Em um ambiente de múltiplos clientes, isso cria uma situação delicada. Imagine que o contêiner A grave informações em um bloco físico e depois seja removido. O bloco retorna ao pool e, posteriormente, é atribuído ao contêiner B.
Se o novo contêiner escrever apenas uma pequena parte daquele espaço, o restante poderá continuar contendo bytes deixados pelo workload anterior.
É justamente essa condição que transformou uma otimização de armazenamento em um problema de isolamento entre tenants.
Como os pesquisadores recuperaram os dados antigos
A prova de conceito demonstrou o problema de maneira relativamente simples.
Os pesquisadores conseguiram provocar a utilização de um bloco de 64 KiB e gravaram somente 4 KiB de dados. Os 60 KiB restantes não foram sobrescritos.
Como o bloco físico havia sido reutilizado sem zeramento, os bytes restantes poderiam conter dados deixados por um contêiner anterior.
A diferença entre o tamanho da gravação e o tamanho do bloco é fundamental para compreender o problema:
64 KiB de bloco físico – 4 KiB gravados pelo novo workload = 60 KiB potencialmente preservados.
A técnica não representava uma leitura direta do sistema de arquivos de outro cliente. O acesso acontecia em uma camada inferior, aproveitando o fato de que os bytes antigos continuavam fisicamente presentes no armazenamento.
Isso também explica por que mecanismos convencionais de permissões de arquivos não seriam suficientes para impedir o problema. O risco existia antes da camada tradicional do sistema de arquivos, durante a reutilização dos blocos físicos.
Quais dados poderiam aparecer nos blocos reutilizados
Os testes encontraram diferentes tipos de informações residuais. Entre os dados identificados estavam estruturas de diretórios, páginas de bancos de dados SQLite, perfis do Chromium e arquivos .env.
A presença de arquivos .env é particularmente relevante para ambientes de desenvolvimento. Esses arquivos frequentemente armazenam variáveis de ambiente, tokens, chaves de API e credenciais utilizadas por aplicações.
Também foram observadas páginas pertencentes a bancos de dados SQLite. Mesmo que apenas fragmentos sejam recuperados, esse tipo de informação pode revelar dados sobre uma aplicação ou seu estado anterior.
Entretanto, a vulnerabilidade não permitia que o pesquisador escolhesse livremente qual cliente atacar ou quais dados recuperar. Segundo a Cloudflare, a técnica dependia de condições específicas de reutilização do armazenamento, e não havia garantia de que um determinado bloco conteria informações interessantes.
Esse detalhe é importante para dimensionar corretamente o problema. O risco estava na possibilidade de cruzamento acidental de dados entre workloads, e não em um mecanismo que fornecesse acesso determinístico ao armazenamento de qualquer cliente.
Como a Cloudflare corrigiu o problema em duas etapas
A Cloudflare adotou uma correção em duas etapas, porque apenas modificar o comportamento das novas alocações não seria suficiente para lidar com blocos que já haviam sido utilizados.
A primeira medida foi remover a configuração skip_block_zeroing. Com isso, novos blocos físicos passaram novamente a ser zerados antes de serem disponibilizados para novos volumes.
Essa mudança interrompeu o mecanismo explorado na prova de conceito. Os pesquisadores confirmaram posteriormente que a técnica utilizada para recuperar os dados residuais havia deixado de funcionar.
Porém, havia uma segunda questão: dados antigos já existentes no ambiente não seriam apagados simplesmente pela alteração da configuração.
Por esse motivo, a Cloudflare realizou uma segunda etapa de limpeza, envolvendo a retirada de discos de contêineres, drenagem de servidores, reinicialização de máquinas virtuais e limpeza de caches de imagens e snapshots criados antes da aplicação da correção.
Esse procedimento é importante porque demonstra uma diferença fundamental entre corrigir uma vulnerabilidade e eliminar os resíduos deixados pela condição vulnerável.
A nova configuração impede que o problema continue acontecendo, enquanto a limpeza da infraestrutura reduz o risco representado pelos dados que poderiam permanecer armazenados nos blocos antigos.
O que o problema revela sobre o thin provisioning do Linux
O caso também serve como exemplo de como uma configuração aparentemente pequena pode ter consequências importantes em uma infraestrutura compartilhada.
O thin provisioning existe justamente para aumentar a eficiência do armazenamento. Em vez de reservar fisicamente todo o espaço de um volume virtual antecipadamente, o sistema administra um pool e distribui blocos conforme eles são necessários.
O problema aparece quando essa reutilização ocorre entre diferentes níveis de confiança.
Em um servidor dedicado a uma única organização, deixar de zerar blocos pode representar uma decisão de desempenho com impacto diferente. Em uma plataforma multi-tenant, entretanto, o mesmo comportamento precisa ser analisado sob a perspectiva da confidencialidade.
A opção skip_block_zeroing é um bom exemplo disso. Ao evitar o zeramento dos blocos, operações de armazenamento podem ser reduzidas, mas o conteúdo anterior precisa ser tratado por alguma outra camada de isolamento ou sanitização.
A documentação do device-mapper thin provisioning do Linux descreve justamente o funcionamento desse mecanismo e as opções relacionadas ao zeramento de blocos.
Cloudflare investigou possíveis sinais de exploração
Depois de identificar e corrigir o problema, a Cloudflare também analisou seus registros para verificar se a vulnerabilidade havia sido utilizada por terceiros.
Segundo a empresa, a investigação não encontrou evidências de exploração maliciosa. Os eventos compatíveis com a técnica estavam relacionados aos testes realizados pelos pesquisadores e pelos próprios engenheiros da Cloudflare durante a investigação.
A empresa também destacou limitações importantes da exploração. O método não permitia escolher diretamente um determinado servidor, cliente ou conjunto de dados. A recuperação dependia da reutilização de um bloco físico específico e da existência de informações residuais naquela região.
Ainda assim, a possibilidade de recuperar dados pertencentes a outro workload é suficiente para transformar o comportamento do armazenamento em uma questão de segurança.
Em ambientes de nuvem, confidencialidade não depende apenas de permissões, namespaces ou hypervisors. A camada física e os mecanismos responsáveis pela reutilização do armazenamento também fazem parte da superfície de ataque.
O impacto no isolamento entre contêineres
O episódio envolvendo o Cloudflare Containers mostra que o isolamento de workloads possui várias camadas.
É possível ter um contêiner corretamente isolado do sistema operacional hospedeiro e, ao mesmo tempo, existir uma falha em uma camada inferior capaz de expor informações de outro workload.
Nesse caso, não foi necessário explorar um container escape, obter privilégios administrativos ou quebrar diretamente o isolamento de uma máquina virtual. O problema surgiu na forma como blocos físicos eram reutilizados.
Para administradores de sistemas e equipes DevOps, essa é uma lição relevante. Configurações de LVM thin pools, device-mapper, snapshots, volumes temporários e caches de imagens precisam ser avaliadas não apenas pelo desempenho, mas também pelo risco de exposição de dados residuais.
Também é importante diferenciar liberar um bloco, descartar um bloco e sanitizar seu conteúdo. Essas operações não são necessariamente equivalentes e podem depender da implementação utilizada em cada camada do armazenamento.
A correção aplicada pela Cloudflare reforça ainda outro princípio: quando uma vulnerabilidade envolve armazenamento, corrigir o mecanismo de alocação e limpar os dados previamente acumulados são tarefas diferentes.
Para ambientes próprios de Docker, LXC, Kubernetes ou outras plataformas de contêineres, vale revisar como os volumes são criados, reutilizados e descartados, especialmente quando workloads de diferentes usuários ou projetos compartilham o mesmo pool físico.
O caso também mostra por que o Linux continua sendo uma peça central na segurança da infraestrutura em nuvem. Componentes aparentemente invisíveis para o usuário final, como o device-mapper e os mecanismos de gerenciamento de blocos, podem ter impacto direto sobre a confidencialidade dos dados.
A Cloudflare informou que concluiu as medidas necessárias para eliminar a condição vulnerável e que não identificou evidências de exploração maliciosa. Para os clientes, a empresa indicou que não seria necessária nenhuma ação adicional.
