Interrupção da Cloudflare em 5 de dezembro de 2025

Em 5 de dezembro de 2025, às 08:47 UTC (todos os horários neste blog são UTC), uma parte da rede da Cloudflare começou a apresentar falhas significativas. O incidente foi resolvido às 09:12 (aproximadamente 25 minutos de impacto total), quando todos os serviços foram totalmente restaurados.

Um subconjunto de clientes foi afetado, representando aproximadamente 28% de todo o tráfego HTTP atendido pela Cloudflare. Vários fatores precisaram se combinar para que um cliente individual fosse afetado, conforme descrito abaixo.

O problema não foi causado, direta ou indiretamente, por um ataque cibernético aos sistemas da Cloudflare ou atividade maliciosa de qualquer natureza. Em vez disso, ele foi acionado por alterações feitas em nossa lógica de análise de corpo ao tentar detectar e mitigar uma vulnerabilidade do setor divulgada esta semana nos componentes do Servidor React.

Qualquer interrupção de nossos sistemas é inaceitável e sabemos que decepcionamos a internet novamente após o incidente de 18 de novembro. Na próxima semana, vamos publicar detalhes sobre o trabalho que estamos realizando para evitar que esses tipos de incidentes ocorram.

O gráfico abaixo mostra os erros HTTP 500 fornecidos pela nossa rede durante o período do incidente (linha vermelha na parte inferior), em comparação com o tráfego total da Cloudflare não afetado (linha verde na parte superior).

O firewall de aplicativos web (WAF) da Cloudflare oferece aos clientes proteção contra conteúdos maliciosos, permitindo que sejam detectados e bloqueados. Para fazer isso, o proxy da Cloudflare armazena o conteúdo do corpo da solicitação HTTP em buffer na memória para análise. Anteriormente, o tamanho do buffer era definido em 128 KB.

Como parte do nosso trabalho contínuo para proteger os clientes que usam o React contra uma vulnerabilidade crítica, a CVE-2025-55182, começamos a implementar um aumento no tamanho do nosso buffer para 1 MB, o limite padrão permitido pelos aplicativos Next.js. Queríamos garantir que o maior número possível de clientes estivesse protegido.

Essa alteração estava sendo implementada usando nosso sistema de implantação gradual e, como parte dessa implementação, identificamos um aumento nos erros em uma de nossas ferramentas internas, que usamos para testar e aprimorar novas regras de WAF. Como se tratava de uma ferramenta interna, e a correção implementada era uma melhoria de segurança, decidimos desabilitar a ferramenta temporariamente, pois não era necessária para atender ou proteger o tráfego de clientes.

A desativação foi feita usando nosso sistema de configuração global. Esse sistema não usa implementações graduais, mas sim propaga as alterações em segundos para toda a rede e está em análise após a interrupção que sofremos recentemente em 18 de novembro.

Na versão FL1 do nosso proxy, em determinadas circunstâncias, essa última alteração causou um estado de erro que resultou no fornecimento de códigos de erro HTTP 500 pela nossa rede.

Assim que a alteração se propagou para nossa rede, a execução de código em nosso proxy FL1 atingiu uma falha em nosso módulo de regras, o que levou à seguinte exceção LUA:

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

resultando na emissão de erros de código HTTP 500.

O problema foi identificado logo após a aplicação da alteração e foi revertido às 09h12. Depois disso, todo o tráfego voltou a ser atendido corretamente.

Os clientes que tinham seus ativos da web atendidos por nosso proxy FL1 mais antigo E que tinham o conjunto de regras gerenciadas da Cloudflare implantado foram afetados. Todas as solicitações para sites neste estado retornaram um erro HTTP 500, com a pequena exceção de alguns endpoints de teste, como /cdn-cgi/trace.

Os clientes que não tiham a configuração acima aplicada não foram afetados. O tráfego de clientes atendido pela China network também não foi impactado.

O sistema de conjuntos de regras da Cloudflare consiste em conjuntos de regras que são avaliadas para cada solicitação que entra em nosso sistema. Uma regra consiste em um filtro, que seleciona algum tráfego, e uma ação que aplica um efeito a esse tráfego. As ações típicas são “block”, “log”, ou “skip”. Outro tipo de ação é “execute”,que é usada para acionar a avaliação de outro conjunto de regras.

Nosso sistema de registro de logs interno usa este recurso para avaliar novas regras antes de disponibilizá-las ao público. Um conjunto de regras de nível superior executa outro conjunto de regras que contém regras de teste. Eram estas regras de teste que estávamos tentando desativar.

Temos um subsistema killswitch (bloqueio de rede) como parte do sistema de conjunto de regras, projetado para permitir a desativação rápida de uma regra com comportamento inadequado. Esse sistema killswitch recebe informações do nosso sistema de configuração global, mencionado nas seções anteriores. Já utilizamos esse sistema killswitch em diversas ocasiões para mitigar incidentes e possuímos um Procedimento Operacional Padrão bem definido, que foi seguido neste incidente.

No entanto, nunca aplicamos um killswitch a uma regra com a ação de "execute". Quando o killswitch foi aplicado, o código ignorou corretamente a avaliação da ação de execução e não avaliou o subconjunto de regras apontado por ela. No entanto, um erro foi encontrado durante o processamento dos resultados gerais da avaliação do conjunto de regras:

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

Este código espera que, se o conjunto de regras tiver a action="execute", o objeto "rule_result.execute" exista. No entanto, como a regra foi ignorada, o objeto "rule_result.execute" não existia e Lua retornou um erro devido à tentativa de buscar um valor em um valor nulo.

Este é um erro simples no código, que permaneceu sem ser detectado por muitos anos. Esse tipo de erro de erro de código é evitado por linguagens com sistemas de tipos fortes. Em nossa substituição desse código no novo proxy FL2, escrito em Rust, o erro não ocorreu.

Duas semanas atrás, em 18 de novembro de 2025, fizemos uma alteração não relacionada que causou um incidente de disponibilidade semelhante porém mais prolongado. Em ambos os casos, uma implementação para ajudar a mitigar um problema de segurança para nossos clientes se propagou por toda a nossa rede e causou erros para quase toda a nossa base de clientes.

Após o incidente, conversamos diretamente com centenas de clientes e compartilhamos nossos planos de implementar mudanças para evitar que atualizações isoladas causem um impacto generalizado como este. Acreditamos que essas mudanças teriam ajudado a evitar o impacto do incidente de hoje, mas, infelizmente, ainda não as implantamos por completo.

Sabemos que é decepcionante que esse trabalho ainda não tenha sido concluído. Ele continua sendo nossa prioridade número um em toda a organização. Em particular, os projetos descritos abaixo devem ajudar a conter o impacto desses tipos de mudanças:

• Implementações e controle de versão aprimorados: assim como implementamos software gradualmente com validação de integridade rigorosa, os dados usados para resposta rápida a ameaças e configuração geral precisam ter os mesmos recursos de segurança e mitigação de explosões. Isso inclui validação de integridade e recursos de reversão rápida, entre outras coisas.

• Recursos de break glass otimizados: garantem que as operações críticas ainda possam ser realizadas diante de tipos adicionais de falhas. Isso se aplica tanto aos serviços internos quanto a todos os métodos padrão de interação com o plano de controle da Cloudflare, utilizados por todos os clientes da Cloudflare.

• Tratamento de erros "Fail-Open": como parte do esforço de resiliência, estamos substituindo a lógica de falha rígida aplicada incorretamente em todos os componentes críticos do plano de dados da Cloudflare. Se um arquivo de configuração estiver corrompido ou fora do intervalo (por exemplo, excedendo os limites de recursos), o sistema registrará o erro e retornará a um estado válido conhecido ou permitirá o tráfego sem pontuação, em vez de descartar as solicitações. Alguns serviços provavelmente oferecerão ao cliente a opção de fail-open ou fail-closed em determinados cenários. Isso incluirá recursos de prevenção de desvios para garantir que seja aplicado continuamente.

Antes do final da próxima semana, publicaremos uma análise detalhada de todos os projetos de resiliência em andamento, incluindo os listados acima. Enquanto esse trabalho estiver em andamento, estamos bloqueando todas as alterações em nossa rede para garantir que tenhamos sistemas de mitigação e reversão melhores antes de começarmos novamente.

Esse tipo de incidente, e a frequência com que ocorreram, é inaceitável para uma rede como a nossa. Em nome da equipe da Cloudflare, gostaríamos de nos desculpar pelo impacto e transtorno causados aos nossos clientes e à internet como um todo.