Cloudflare corrige falha que permitia a um container ler dados residuais de outro cliente no disco
25 de Setembro de 2026

Uma falha no Cloudflare Containers permitiu que um cliente pagante lesse dados deixados por containers de outros clientes no mesmo servidor, segundo a Cloudflare e os pesquisadores que descobriram o problema na quinta-feira.

Os dados estavam em espaço de disco usado e depois liberado por containers anteriores, não em cargas de trabalho em execução. Segundo a Cloudflare, um invasor não poderia escolher de quais clientes seriam os dados acessados. A empresa corrigiu a falha em todo o serviço e afirma que os clientes não precisam tomar nenhuma providência.

O Cloudflare Containers executa programas dos clientes em containers hospedados em servidores compartilhados por várias contas. A escolha do servidor fica a cargo da Cloudflare, não do cliente. O Cloudflare Sandboxes, que funciona sobre o Containers e é vendido como um ambiente seguro para executar código não confiável, inclusive código escrito por agentes de IA, também foi afetado.

O problema foi comunicado em 4 de setembro por Oren Yomtov, da empresa de segurança Accomplish, por meio do programa de bug bounty da Cloudflare.

A falha estava na configuração dos discos compartilhados. Cada container recebia um disco criado com um recurso do Linux chamado thin provisioning, que aloca armazenamento em blocos de 64 quilobytes. Quando um container era excluído, seus blocos voltavam para um conjunto compartilhado entre contas de clientes.

Esse conjunto estava configurado para não zerar os blocos antes de entregá-los ao próximo container, embora zerá-los seja normalmente o padrão. Assim, quando um novo container gravava poucos dados em um bloco reutilizado, o espaço restante ainda continha informações do container anterior.

Para acessar esses dados, os pesquisadores gravaram 4 quilobytes em um bloco não utilizado e, em seguida, leram o bloco inteiro diretamente do disco. Os 60 quilobytes que não haviam sido sobrescritos ainda continham dados de um container anterior.

Em testes realizados em ambientes de produção, os pesquisadores afirmaram ter encontrado dados residuais em 18 de 24 tentativas, cada uma feita em um servidor escolhido pela Cloudflare. Também encontraram dados em 20 de 22 máquinas subjacentes, distribuídas por quatro continentes.

Segundo a Cloudflare, os blocos recuperados continham estruturas de diretórios, páginas de bancos de dados e bancos de dados SQLite estruturalmente completos. O relatório dos pesquisadores também menciona listagens de diretórios, bancos de dados SQLite, perfis do navegador Chromium, arquivos .env e arquivos de credenciais pertencentes a outros clientes.

Os pesquisadores afirmaram que seus scripts de análise exibiam apenas contagens e verificações de formato, não o conteúdo dos arquivos. Segundo eles, o material enviado à Cloudflare não continha nomes de terceiros, identificadores, credenciais nem conteúdo recuperado.

A Cloudflare disse que os pesquisadores também confirmaram que os dados recuperados foram mantidos em sigilo e excluídos com segurança após o envio. Eles não demonstraram que a falha permitia alterar dados em uso por outro cliente ou interromper uma carga de trabalho.

A Cloudflare corrigiu o problema em duas etapas. Primeiro, voltou a zerar os blocos antes de entregá-los a novos containers, impedindo o método relatado. Em 14 de setembro, os pesquisadores confirmaram que a prova de conceito já não funcionava.

Essa alteração, porém, não limpava os blocos já associados a discos de containers em execução nem os armazenados temporariamente em cada servidor como camadas de imagem preparadas. Um novo container poderia herdar esses dados e lê-los. Por isso, a Cloudflare também desativou todos os discos de containers em execução e limpou essas áreas de armazenamento temporário, drenando e reiniciando servidores em horários de menor movimento. A limpeza foi concluída em 19 de setembro, e a falha foi divulgada cinco dias depois.

A Cloudflare afirmou que procurou indícios de que outras pessoas tivessem usado o método. A empresa criou assinaturas de detecção com base na prova de conceito dos pesquisadores e em uma cópia própria do ataque, e aplicou essas assinaturas aos registros de atividade dos discos que havia mantido. Encontrou apenas os testes autorizados dos pesquisadores e de seus próprios engenheiros, sem evidências de que outras pessoas tivessem usado aquele método específico.

Essa conclusão se limita aos registros retidos pela Cloudflare. A empresa não informou por quanto tempo eles abrangiam as atividades nem quando a configuração insegura foi implementada pela primeira vez. Portanto, não está claro por quanto tempo os dados ficaram expostos.

Os pesquisadores afirmam, separadamente, que a mesma configuração de disco afetou o produto Browser Run da Cloudflare. Eles descreveram o caso como a sexta fuga de sandbox de código que publicaram desde julho, após descobertas envolvendo o Claude Cowork e o Claude Code, da Anthropic, a ferramenta de linha de comando do Cursor, o Docker e o Codex, da OpenAI. A publicação da Cloudflare citou o Containers e o Sandboxes como produtos afetados, mas não mencionou o Browser Run.

Publicidade

Anuncie no CaveiraTech e coloque sua marca na frente de milhares de profissionais de cybersecurity

Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...