Cloudflare nov/2025: arquivo de features dobra de tamanho e o proxy entra em pânico

01 · CONTEXTO

Um arquivo de características que dobrou de tamanho

Em 18 de novembro de 2025, a partir das 11:20 UTC, a rede da Cloudflare começou a falhar de forma significativa na entrega de tráfego central. O post-mortem oficial da empresa é a fonte deste caso e descarta ataque: o problema não foi causado, direta ou indiretamente, por ataque cibernético nem por atividade maliciosa.

O gatilho foi uma mudança nas permissões de um dos sistemas de banco de dados da empresa, que fez o banco gravar várias entradas num “feature file” usado pelo sistema de Bot Management. O arquivo dobrou de tamanho e foi propagado a todas as máquinas da rede. O software que o lê tinha um limite de tamanho abaixo do tamanho dobrado, e falhou.

O arquivo existe porque o Bot Management inclui um modelo de aprendizado de máquina que gera uma pontuação de bot para cada requisição, e o modelo lê esse arquivo de características. Ele é atualizado a cada poucos minutos e publicado em toda a rede; a Cloudflare considera crítico publicá-lo com frequência e rapidez porque os atacantes mudam de tática depressa.

02 · O GATILHO

Uma consulta sem filtro e um limite de memória pré-alocada

O arquivo é gerado por uma consulta a um cluster ClickHouse. Essa consulta não filtra pelo nome do banco de dados, e depois da mudança das 11:05 passou a devolver colunas duplicadas, vindas das tabelas subjacentes.

1. O arquivo de características é gerado por uma consulta que roda num cluster ClickHouse, a cada cinco minutos.

2. Às 11:05, a mudança de permissões torna explícito o acesso às tabelas subjacentes; a consulta, sem filtro de banco, passa a devolver colunas duplicadas.

3. O arquivo gerado passa a ter muitas linhas de características duplicadas e dobra de tamanho.

4. O arquivo maior é propagado a todas as máquinas que compõem a rede.

5. O arquivo com mais de 200 características atinge o limite do módulo e o sistema entra em pânico.

6. A correção interrompe a geração e a propagação do arquivo ruim, insere manualmente um arquivo bom na fila de distribuição e força o reinício do proxy central.

Cada módulo do proxy tem limites para evitar consumo ilimitado de memória e para pré-alocar memória por desempenho. No Bot Management, o limite era de 200 características, bem acima das cerca de 60 em uso. O arquivo ruim, com mais de 200, atingiu o limite e o sistema entrou em pânico.

O código em Rust do FL2 que faz essa checagem foi a origem de um erro não tratado: o pânico registrado foi uma chamada a unwrap sobre um valor de erro, e isso resultou numa resposta 5xx.

O limite em si é uma defesa razoável de memória. O que merece discussão é o que o módulo faz quando recebe uma entrada que o excede: recusar o arquivo novo e continuar com o anterior, ou deixar o erro subir e falhar a requisição.

03 · O ALCANCE

Um módulo, vários dependentes

O Bot Management é um dos módulos do proxy central, e foi a origem da queda. O proxy central devolveu erros HTTP 5xx a todo tráfego que dependia do módulo de bots.

1. Toda requisição termina nas camadas HTTP e TLS e depois entra no proxy central.

2. Workers KV e Access dependem do proxy central e foram afetados.

3. O Dashboard foi afetado pelo uso interno do Workers KV e pelo Turnstile no login.

4. Um patch no Workers KV e desvios no Access fizeram os dois voltar a uma versão anterior do proxy central, onde o problema existia com impacto menor.

5. Já com o arquivo corrigido, um acúmulo de logins e novas tentativas elevou a latência do dashboard.

Além dos erros 5xx, a latência da CDN aumentou de forma significativa. A fonte atribui isso ao uso intenso de CPU pelos sistemas de depuração e observabilidade, que enriquecem automaticamente os erros não tratados com informações extras.

04 · DIAGNÓSTICO

Oscilação, suspeita de ataque e a volta

O arquivo era gerado a cada cinco minutos por uma consulta num cluster ClickHouse que estava sendo atualizado aos poucos. Dados ruins só saíam quando a consulta rodava numa parte já atualizada, de modo que a cada ciclo havia chance de sair um conjunto de arquivos bom ou ruim, propagado rapidamente.

A oscilação tornou confuso o que acontecia, porque o sistema se recuperava e voltava a falhar. A equipe suspeitou inicialmente, por engano, de um ataque DDoS de hiperescala. A página de status também ficou fora do ar, por coincidência, e isso reforçou a suspeita em parte da equipe.

A investigação inicial partiu do sintoma de resposta degradada no Workers KV, e foram tentadas mitigações como manipulação de tráfego e limitação de contas nesse serviço.

Os erros continuaram até a causa ser identificada e resolvida, a partir das 14:30. A cauda longa foi a equipe reiniciando serviços que tinham entrado em estado ruim, com o volume de 5xx voltando ao normal às 17:06.

05 · LIÇÕES

O que a Cloudflare se propôs a mudar

Entre os passos de remediação, a Cloudflare listou: endurecer a ingestão de arquivos de configuração gerados por ela mesma, como faria com entrada de usuário; habilitar mais kill switches globais para funcionalidades; eliminar a possibilidade de core dumps ou outros relatórios de erro sobrecarregarem recursos do sistema; e revisar os modos de falha das condições de erro em todos os módulos do proxy central.

Um arquivo gerado por outro componente interno continua sendo entrada para quem o consome. Validar formato, tamanho e quantidade de itens antes de aplicar, e ter à mão uma versão anterior boa, são perguntas de projeto de disponibilidade.

Pergunta para discussão: o que muda no desenho se um arquivo que precisa chegar depressa a toda a rede passar por uma etapa de validação e por um lançamento em ondas, no estilo dos padrões de nuvem de implantação gradual? O que se ganha e o que se perde em velocidade?