Cloudflare sofreu nesta terça-feira, 18 de novembro de 2025, a sua pior pane desde 2019. A partir das 11h20 (UTC), a rede da empresa começou a falhar de forma significativa na entrega de tráfego essencial, exibindo para usuários de sites protegidos pela plataforma páginas de erro com falha interna na própria rede da Cloudflare.
A empresa garante que não se tratou de ataque cibernético nem de qualquer atividade maliciosa 👀. O problema nasceu de uma alteração nas permissões de um dos sistemas de banco de dados, que passou a gerar dados errados para um arquivo interno chamado “feature file”, usado pelo sistema de Bot Management.
Esse arquivo, que normalmente tem tamanho controlado, de repente dobrou de tamanho por causa de entradas duplicadas. Mesmo assim, ele foi distribuído normalmente para todas as máquinas que compõem a rede global da Cloudflare.
O software que roteia o tráfego na rede lê esse arquivo de recursos para manter o Bot Management atualizado contra novas ameaças. Só que esse software tinha um limite de tamanho para o arquivo — e esse limite era menor que o novo tamanho. Resultado: o processo falhou em massa, gerando erros 5xx.
No começo, a equipe chegou a suspeitar de um DDoS em larga escala, especialmente porque o comportamento parecia intermitente. Mas, depois, a causa real foi identificada: era o arquivo de configuração de bots quebrado.
Assim que a origem do problema foi confirmada, a Cloudflare interrompeu a propagação do arquivo inflado e colocou no lugar uma versão anterior, considerada “boa”. Por volta de 14h30 o tráfego principal já fluía quase normalmente. A partir daí, a empresa passou algumas horas aliviando a sobrecarga em diferentes partes da rede, causada pelo retorno repentino do tráfego. Às 17h06, todos os sistemas voltaram ao funcionamento normal.
A companhia admite o impacto para clientes e para a Internet como um todo e diz que qualquer indisponibilidade em serviços centrais é “inaceitável”. O fato de a rede ter ficado, por um período, incapaz de rotear tráfego é descrito como “doloroso” para toda a equipe. “Nós decepcionamos vocês hoje”, reconhece a empresa.
Como foi a falha ao longo do dia
Os gráficos internos da Cloudflare mostraram um pico súbito no volume de códigos HTTP 5xx servidos pela rede — número que deveria ser muito baixo em condições normais. Antes de 11h20, o volume de erros estava dentro do esperado; depois disso, houve uma explosão de falhas ligada ao carregamento incorreto do tal “feature file”.
O detalhe curioso é que o sistema se recuperava por alguns minutos e depois quebrava de novo. Esse comportamento estranho ajudou a confundir o diagnóstico inicial.
A explicação veio depois: o arquivo era gerado a cada cinco minutos por uma consulta a um cluster de banco de dados ClickHouse, que estava sendo atualizado gradualmente para melhorar a gestão de permissões. Dados ruins só eram gerados quando a consulta rodava em uma parte do cluster já atualizada; quando caía em um nó ainda não alterado, saía um arquivo “bom”.
Na prática, a cada cinco minutos podia cair tanto um arquivo de configuração válido quanto um corrompido, que era então rapidamente distribuído pela rede. Esse vai-e-volta na qualidade do arquivo fazia o sistema quebrar e se recuperar de forma alternada, parecendo até comportamento de ataque.
Com o avanço da atualização no cluster, todos os nós do ClickHouse passaram a gerar o arquivo incorreto, e as oscilações cederam lugar a um estado de falha contínua. Os erros só começaram a cair quando a raiz do problema foi atacada, a partir de 14h30, com a interrupção da geração do arquivo defeituoso, a inserção manual de um arquivo bom na fila de distribuição e o restart forçado do core proxy.
O “rabo longo” de erros que ainda aparece nos gráficos até 17h06 é explicado pelo processo de reinício de serviços que tinham ficado em estado ruim ao longo do incidente.
Serviços afetados durante a pane
- Core CDN e serviços de segurança: retorno de códigos HTTP 5xx, com páginas de erro aparecendo para usuários finais.
- Turnstile: o serviço deixou de carregar, o que impactou fluxos de login que dependem dele.
- Workers KV: passou a retornar muitos erros 5xx porque o gateway de front-end falhava devido ao problema no core proxy.
- Dashboard: a interface em si continuou relativamente acessível, mas a maioria dos usuários não conseguia fazer login porque o Turnstile estava indisponível na página de autenticação.
- Email Security: o processamento e a entrega de e-mails continuaram funcionando, mas houve perda temporária de acesso a uma fonte de reputação de IP, reduzindo a precisão de detecção de spam e impedindo algumas detecções ligadas à idade de novos domínios; a empresa afirma não ter visto impacto crítico. Também ocorreram falhas em algumas ações de Auto Move; todas as mensagens afetadas foram revistas e corrigidas.
- Access: falhas de autenticação generalizadas para a maioria dos usuários a partir do início do incidente, persistindo até o rollback iniciado às 13h05. Sessões já ativas não foram afetadas.
Todas as tentativas de autenticação fracassadas resultaram em página de erro, o que significa que, durante as falhas, os usuários nem chegavam a acessar as aplicações protegidas. Logins bem-sucedidos nesse intervalo foram registrados corretamente. Atualizações de configuração do Access feitas nesse período ou falharam ou demoraram muito a se propagar; agora todas as mudanças estão recuperadas.
Além dos erros 5xx, a empresa viu um aumento expressivo na latência das respostas da CDN. Isso foi atribuído ao grande consumo de CPU pelos sistemas de debug e observabilidade, que automaticamente enriquecem erros não tratados com mais contexto de depuração 🔍.
O caminho do tráfego na Cloudflare — e onde tudo quebrou
Qualquer requisição que passa pela Cloudflare segue um fluxo bem definido: pode ser um navegador carregando página, um app mobile chamando API ou tráfego automatizado de outro serviço. Tudo começa na camada HTTP/TLS, segue para o sistema de proxy central — chamado FL (“Frontline”) — e então passa pelo Pingora, que cuida de buscar no cache ou no servidor de origem.
É nesse core proxy que rodam os produtos de segurança e performance, aplicando as configurações específicas de cada cliente: de regras de WAF e proteção contra DDoS até roteamento para a Developer Platform e o R2. Cada parte disso é executada por módulos especializados.
Um desses módulos é o de Bot Management, justamente a origem do apagão de hoje.
O Bot Management usa, entre outros recursos, um modelo de machine learning que gera uma pontuação de bot para cada requisição. Clientes usam essa pontuação para decidir quais bots podem ou não acessar seus sites.
Para funcionar, o modelo consome um arquivo de configuração de “features” — ou seja, características usadas para prever se um pedido é automatizado. Esse arquivo, que é uma coleção dessas features, é atualizado a cada poucos minutos e distribuído para toda a rede, permitindo reagir rapidamente a novos tipos de bots e ataques automatizados.
Uma mudança no comportamento da consulta ao banco de dados ClickHouse que gera esse arquivo fez com que ele passasse a incluir um grande número de linhas de feature duplicadas. Isso aumentou o tamanho do arquivo, que antes era relativamente estável, e fez o módulo de bots disparar erro.
Com isso, o core proxy passou a devolver códigos HTTP 5xx para qualquer tráfego que dependesse do módulo de bots. Workers KV e Access, que se apoiam nesse proxy, também foram afetados.
Ao mesmo tempo, a Cloudflare está em plena migração de tráfego para uma nova versão do serviço de proxy, chamada internamente de FL2. Tanto o FL2 quanto o FL antigo sofreram impacto — mas de formas diferentes.
- Clientes já migrados para o FL2 viram erros HTTP 5xx.
- Clientes ainda no FL antigo não receberam erros, mas tiveram pontuações de bot geradas de forma errada: todo o tráfego recebia score igual a zero.
Para quem tinha regras configuradas para bloquear bots com base nessa pontuação, isso significou uma enxurrada de falsos positivos. Quem não usava o score em regras não foi afetado nesse ponto.
Para piorar a suspeita inicial de ataque, a página de status da própria Cloudflare saiu do ar. Ela é hospedada fora da infraestrutura da empresa e, em teoria, não depende de nada da Cloudflare. A coincidência reforçou a impressão de que poderia haver um ataque coordenado tanto contra a rede quanto contra o status page.
Quem tentou acessar a página de status nesse momento viu uma mensagem de erro. Dentro dos canais internos, engenheiros chegaram a levantar a hipótese de relação com a onda recente de ataques DDoS de alto volume atribuídos ao grupo Aisuru. No fim, tratou-se apenas de coincidência.
O que mudou no banco de dados ClickHouse
O coração técnico do problema esteve numa alteração aparentemente simples de controle de acesso no ClickHouse.
Para entender, é útil lembrar como funcionam queries distribuídas no ClickHouse. Um cluster é composto por vários shards. Para consultar dados em todos eles, existem as chamadas “tabelas distribuídas” (via engine Distributed) em um banco chamado default. Essas tabelas distribuídas encaminham consultas para tabelas subjacentes em outro banco, o r0, onde os dados de fato ficam armazenados em cada shard.
Consultas a essas tabelas distribuídas eram executadas por uma conta de sistema compartilhada. Como parte de um esforço de segurança e confiabilidade, a Cloudflare vinha migrando essas consultas para rodarem sob as contas de usuário originais, permitindo aplicar limites e permissões de forma mais granular.
Antes da mudança, ao consultar metadados nas tabelas de sistema do ClickHouse, como system.tables ou system.columns, um usuário só enxergava as tabelas do banco default.
Às 11h05, entrou no ar uma mudança para tornar explícito o acesso às tabelas subjacentes do banco r0. Assim, usuários passariam a ver também os metadados dessas tabelas, alinhando o que eles realmente já podiam ler de forma implícita.
Na teoria, isso daria mais controle: todas as subconsultas distribuídas passariam a rodar sob o usuário inicial, permitindo aplicar limites detalhados e impedir que uma subconsulta malcomportada impactasse outros usuários.
Na prática, porém, havia um pressuposto antigo no código: de que uma consulta aos metadados de colunas retornaria apenas o que está no banco default. O exemplo citado:
SELECT
name,
type
FROM system.columns
WHERE
table = 'http_requests_features'
ORDER BY name;
Note que a query não filtra por nome de banco. Com a mudança de permissões, ela passou a trazer também colunas das tabelas equivalentes no banco r0, o que na prática gerou “duplicatas” de colunas na resposta.
Justamente essa era a consulta usada pela lógica de geração do arquivo de features do Bot Management. Com a resposta “inflada”, o arquivo final ganhou bem mais linhas (mais features) do que o esperado.
O limite de features e o pânico do sistema
Cada módulo que roda no proxy da Cloudflare respeita limites internos para evitar consumo descontrolado de memória e, ao mesmo tempo, pré-alocar recursos como otimização de performance.
No caso do Bot Management, existe um limite de quantas features de machine learning podem ser usadas em tempo de execução. Hoje, esse teto é 200, número bem acima das cerca de 60 features que a empresa costuma usar.
Esse limite existe porque o sistema pré-aloca memória para as features antes de usá-las. Quando o arquivo “quebrado”, com mais de 200 features, foi distribuído para os servidores, esse limite estourou — e o módulo entrou em pânico.
No FL2, o código em Rust responsável por fazer essa checagem gerou um erro não tratado (um unwrap em resultado de erro), disparando um panic numa thread de trabalho:
thread fl2_worker_thread panicked: called Result::unwrap() on an Err value
Cada um desses pânicos se traduzia em respostas HTTP 5xx para o tráfego afetado.
Impactos adicionais e mitigação parcial
Serviços que dependem diretamente do core proxy, como Workers KV e Cloudflare Access, também sofreram. Às 13h04, a equipe implementou um patch para o Workers KV que fazia o serviço contornar o core proxy, reduzindo o impacto. Como vários sistemas internos — inclusive o próprio Access — confiam no Workers KV, eles também passaram a ver menor taxa de erros após esse bypass.
O Dashboard foi atingido em duas frentes: pelo uso interno de Workers KV e pelo uso do Turnstile no fluxo de login.
O Turnstile, afetado pela pane, deixou muitos clientes sem conseguir se autenticar no painel, a não ser aqueles que já tinham sessão ativa. A indisponibilidade do serviço foi mais intensa em dois períodos: das 11h30 às 13h10 e das 14h40 às 15h30.
No primeiro intervalo, a falha veio da degradação do Workers KV, do qual dependem algumas funções de plano de controle e do dashboard. Às 13h10, com o bypass do KV em relação ao core proxy, essa parte foi estabilizada.
O segundo pico de impacto no painel aconteceu após a restauração do arquivo de configuração de features. Um grande acúmulo de tentativas de login começou a sobrecarregar o dashboard. Essa combinação de backlog com tentativas de retry elevou a latência e reduziu a disponibilidade da interface. Aumentar a concorrência do plano de controle resolveu o gargalo por volta de 15h30.
O que a Cloudflare promete fazer agora 🛠️
Com os sistemas de volta ao normal, a Cloudflare já lista uma série de ações para reforçar a resiliência contra falhas desse tipo:
- Endurecer a ingestão de arquivos de configuração gerados pela própria Cloudflare, tratando-os com o mesmo rigor usado para entrada de dados de usuários.
- Ativar mais “kill switches” globais para desligar rapidamente funcionalidades problemáticas.
- Eliminar a possibilidade de que core dumps ou relatórios de erro sobrecarreguem recursos de sistema.
- Revisar modos de falha e tratamento de erros em todos os módulos do core proxy.
A empresa lembra que, embora já tenha lidado com panes que derrubaram o dashboard ou recursos mais novos, não via desde 2019 um incidente capaz de interromper o fluxo da maior parte do tráfego essencial na sua rede.
A avaliação interna é direta: um apagão como o de hoje é “inaceitável”. A arquitetura foi projetada para ser altamente resiliente, de modo que o tráfego continue fluindo mesmo diante de falhas. E, historicamente, cada incidente levou a novos mecanismos de resiliência.
Em nome de toda a equipe, a Cloudflare pede desculpas “pela dor causada à Internet hoje”.
Linha do tempo do incidente (UTC)
- 11:05 — Operação normal. É feita a alteração de controle de acesso no banco de dados.
- 11:28 — Início do impacto. A mudança atinge ambientes de clientes e os primeiros erros aparecem no tráfego HTTP.
- 11:32–13:05 — A equipe investiga aumento de erros e tráfego no serviço Workers KV. A hipótese inicial é de degradação do KV, com efeito cascata em outros serviços. São tentadas mitigações como manipulação de tráfego e limitação de contas para estabilizar o KV. O primeiro teste automatizado detecta o problema às 11:31, a investigação manual começa às 11:32 e a chamada oficial de incidente é aberta às 11:35.
- 13:05 — Implementados bypasses internos para Workers KV e Cloudflare Access, fazendo-os voltarem temporariamente a uma versão anterior do core proxy. O problema também existia nessa versão, mas com impacto menor.
- 13:37 — Foco total em fazer rollback do arquivo de configuração do Bot Management para uma versão “última conhecida boa”. A essa altura, a equipe já está confiante de que o arquivo de bots é o gatilho do incidente, e passa a trabalhar em paralelos diferentes — o caminho mais rápido é restaurar um arquivo antigo.
- 14:24 — É interrompida a criação e propagação de novos arquivos de configuração do Bot Management. Confirma-se que o módulo de bots é a fonte dos erros 500, causados por um arquivo de configuração ruim.
- 14:24 — Concluído o teste com o arquivo antigo, que mostra recuperação bem-sucedida. O foco passa a ser acelerar a correção globalmente.
- 14:30 — Principais impactos são resolvidos. O arquivo correto é distribuído globalmente e a maioria dos serviços volta a operar normalmente, com serviços dependentes observando quedas nas taxas de erro.
- 17:06 — Todos os serviços são declarados totalmente recuperados. Downstreams são reiniciados e as operações retornam ao estado normal.
No fim, a Cloudflare reforça o papel da sua “connectivity cloud”: proteger redes corporativas inteiras, ajudar clientes a construir aplicações em escala de Internet, acelerar sites, mitigar DDoS e manter invasores afastados — e, ainda, apoiar estratégias de Zero Trust. Hoje, porém, esse ecossistema sentiu como um único arquivo interno malformado pode derrubar uma engrenagem crítica da Internet moderna.