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

• Em 5 de dezembro de 2025 às 08:47 UTC, uma interrupção grave afetou parte da rede da Cloudflare e foi completamente restaurada 25 minutos depois, às 09:12
• Cerca de 28% de todo o tráfego HTTP foi impactado, e apenas clientes que atendiam a critérios específicos sofreram a interrupção
• A causa foi uma alteração na lógica de parsing do body do WAF feita durante a mitigação da vulnerabilidade do React Server Components (CVE-2025-55182), sem relação com ataque cibernético
• O erro de código no proxy FL1 causou erros HTTP 500, enquanto o novo proxy FL2, baseado em Rust, não apresentou o mesmo erro
• A Cloudflare reconheceu que um problema semelhante foi repetido após a interrupção de 18 de novembro e está conduzindo o projeto de melhoria da resiliência e da segurança de implantação como prioridade máxima

---

Visão geral da interrupção

• Em 5 de dezembro de 2025 às 08:47 UTC houve uma interrupção em parte da rede da Cloudflare
  • 09:12 recuperada totalmente, com impacto total de 25 minutos
  • Aproximadamente 28% do tráfego HTTP total foi impactado
• A interrupção foi desvinculada de ataques cibernéticos ou ações maliciosas, tendo ocorrido durante uma alteração interna de configuração
• A causa foi uma alteração na lógica de parsing do corpo no WAF para resposta a uma nova vulnerabilidade do React Server Components

Causa e contexto técnico

• O WAF da Cloudflare armazena em buffer o corpo da requisição HTTP na memória para detectar cargas úteis maliciosas
  • Estava em andamento a expansão do tamanho padrão do buffer de 128 KB para 1 MB
• Como a ferramenta de teste interna não dava suporte ao novo tamanho de buffer, foi feita uma segunda mudança para desativar a ferramenta de testes
  • Essa mudança foi propagada instantaneamente para todos os servidores por meio do sistema de configuração global
• Essa alteração no proxy FL1 causou um estado de erro, gerando resposta HTTP 500
  • Mensagem de erro: attempt to index field 'execute' (a nil value)
• O problema foi rapidamente identificado e a mudança revertida às 09:12

Alcance do impacto

• Apenas clientes usando o proxy FL1 e com o Cloudflare Managed Ruleset aplicado foram impactados
  • Todas as requisições desses sites retornaram erro HTTP 500
  • Endpoints de teste como /cdn-cgi/trace foram exceção
• A rede da China e clientes com outras arquiteturas não foram afetados

Detalhes do erro em tempo de execução

• O sistema de rulesets da Cloudflare avalia regras por requisição
  • As regras são compostas por filtros e ações, e a ação execute chama outro conjunto de regras
• O sistema interno de logs avaliava regras de teste usando a ação execute
• O killswitch foi projetado para desativar regras que começam a falhar, porém
  • Esta foi a primeira vez em que o killswitch foi aplicado a uma regra com a ação execute
• O erro foi causado por tentativa de acesso ao objeto execute quando ele não existia, gerando erro em Lua
• Esse é um bug simples de código que existia há anos, mas permaneceu não detectado
  • No proxy FL2 escrito em Rust, o mesmo erro não ocorreu

Progresso após a interrupção de 18 de novembro

• Em 18 de novembro houve também uma interrupção ampla por implantação global semelhante
• Na época, a Cloudflare se comunicou diretamente com centenas de clientes e compartilhou um plano para evitar a expansão irrestrita de uma única atualização
• Como esse trabalho de melhoria ainda não havia sido concluído, ele impactou esta interrupção
• A Cloudflare classificou isso como prioridade máxima da organização

Projetos de reforço de resiliência em andamento

• Enhanced Rollouts & Versioning
  • Aplicar implantação gradual, validação de saúde e rollback rápido também a mudanças de dados e configurações para resposta a ameaças
• Streamlined Break Glass Capabilities
  • Garantir capacidade de operação de emergência também durante interações entre serviços internos e o plano de controle
• Tratamento de falhas fail-open
  • Em caso de erro de arquivo de configuração, não bloquear a requisição e retornar ao estado normal padrão ou permitir a passagem de tráfego
  • Opção de escolha entre fail-open/fail-closed ficará disponível para alguns serviços
• Detalhes de todos os projetos de resiliência serão divulgados até a próxima semana
• Até lá, as mudanças de rede ficarão em estado de lockdown total

Linha do tempo (UTC)

• 08:47 – início da distribuição da mudança de configuração e propagação pela rede
• 08:48 – impacto total
• 08:50 – incidente declarado por alerta automático
• 09:11 – início do rollback da mudança
• 09:12 – recuperação concluída e normalização de todo o tráfego

Conclusão

• A Cloudflare reconheceu a gravidade de duas interrupções consecutivas e pediu desculpas aos clientes e a toda a internet
• Pretende avançar com a prevenção de incidentes semelhantes por meio de maior segurança na implantação, tolerância a erros e reforço da resiliência

[GN⁺]

Comentários do Hacker News

• Esta falha do Cloudflare não foi apenas um bug simples em Lua, mas um incidente que revelou um problema de arquitetura fundamental
  A estrutura web distribuída original era muito mais resistente a esse tipo de falha global. Já sistemas centralizados e homogêneos como o Cloudflare podem parar serviços no mundo inteiro ao mesmo tempo por causa de um único erro. Mesmo sendo escrito em Rust, humanos erram. No fim, o que importa é um projeto robusto

  • No fim das contas, isso significa que, quanto mais dependemos de gigantes como Cloudflare ou AWS, menor é a estabilidade da web
  • Como na analogia “1.000 vespas vs 1 cachorro”, seja uma falha global ou local, só muda a forma do sofrimento. Quando o Cloudflare cai, centenas de engenheiros reagem na hora; quando meu servidor cai, o responsável pode estar numa cabana nas montanhas
  • Deixando de lado a discussão sobre monopólio, olhando o uptime de longo prazo do Cloudflare, ele ainda parece melhor do que cada site operar sua própria infraestrutura. Pela lógica do usuário, é melhor que todos os serviços parem por 1 hora ao mesmo tempo do que cada um cair separadamente por 1 hora. Mas se a estabilidade do Cloudflare cair para abaixo da média, esse valor desaparece
  • Numa escala de 80 milhões de requisições por segundo, talvez o problema seja a própria estrutura em que um único produto cresce desse jeito
  • O Cloudflare ainda é uma das empresas que mais rapidamente restaura infraestrutura global em qualquer lugar do mundo. Desta vez também resolveu uma falha de 28% da rede em 25 minutos, e objetivamente tem menos downtime do que outras clouds

• Ontem à noite vi erros 500 do Cloudflare em vários sites. Mas não havia nenhuma menção na página de status, só aviso de manutenção programada

  • Como acontece na maioria das páginas de status, leva tempo até reconhecerem o problema real e atualizarem a informação. Até isso ser totalmente automatizado, o Cloudflare não é exceção. Mais preocupante é ver AWS, Azure e Cloudflare caindo em sequência recentemente. Meu palpite é que há uma combinação de aumento no uso de LLMs, falta de pessoal, efeitos da pandemia e instabilidade política
  • Esse tipo de problema com página de status só deve melhorar por meio de crítica pública. Precisa haver mais feedback do tipo “o Cloudflare nem consegue detectar a própria falha direito”

• Parece que a engenharia de qualidade do Cloudflare não está acompanhando a velocidade de produção. Já ouvi dizer que, antigamente, na indústria de defesa, a equipe de qualidade era sempre mais experiente, mas na indústria de software parece o contrário

  • Isso lembra um caso na indústria de defesa em que sabiam de um vazamento de memória, mas ignoraram dizendo “durante o tempo de uso não dá problema”
  • Isso aconteceu duas vezes no mesmo mês, então não é algo “digno de elogio”. Repetição não tem desculpa

• A estrutura de comutação de pacotes da internet foi originalmente projetada para resistir a esse tipo de falha global.
  Na Guerra Fria, a rede da DARPA tinha como objetivo manter a cadeia de comando mesmo sob ataque nuclear.
  Agora é a hora de voltar ao paradigma local-first da internet

  • Referência: The Real Internet Architecture
  • Referência: Local-first software

• Ultimamente tenho a sensação de que o Cloudflare está tornando a internet mais lenta e incômoda. Aumentaram os processos como “prove que você é humano”, e o carregamento das páginas também está mais demorado.
  Isso parece estar ligado mais à política de cobrança para crawlers de IA do que à proteção dos sites (Apresentação do Pay-per-crawl)

  • Esses procedimentos de verificação humana não são compatíveis com navegadores antigos, e alguns sites acabam ficando totalmente inacessíveis
  • Mas também é um problema quando IAs raspam conteúdo sem permissão. O Cloudflare está oferecendo aos donos dos sites uma opção de proteção de conteúdo, e quem não quiser pode desativar
  • Também surgiu o sarcasmo: “agora nem conseguem mais nos vigiar em segredo”

• O sistema de configuração global do Cloudflare é arriscado porque propaga mudanças para a rede inteira em poucos segundos, sem rollout gradual.
  Quando uma mudança de configuração causa erro, é preciso haver um sistema que permita identificar imediatamente a correlação

  • O problema é que o alerta disparou tarde demais. Veio em 2 minutos, quando deveria ter detectado em segundos.
    Quem fez o deploy deveria estar olhando métricas em tempo real e apertado imediatamente o botão de rollback.
    Até a linha de código aparecia claramente nos logs, mas parece que havia uma desconexão entre a equipe de deploy e quem entendia o código
  • Ao ver os sinais de alerta, tentaram fazer rollback, mas parece que esse processo acabou causando ainda mais problema
  • Ferramentas internas muitas vezes têm muitos falsos positivos e às vezes elas mesmas estão quebradas
  • Parece a piada: “a luz de alerta do motor acendia o tempo todo, então simplesmente arrancaram a lâmpada”

• O uptime do Cloudflare caiu abaixo de 99,9%. Está pior do que o PC da minha casa

  • Com a AWS é a mesma coisa. Se a razão de existir da nuvem é “maior disponibilidade”, então, se é caro e instável, há motivo suficiente para hospedar por conta própria
  • Mas em self-hosting, se houver falha de hardware ou de backup, a recuperação pode levar dias
  • Em lugares com quedas frequentes de energia, é difícil até se manter com notebook e bateria. Às vezes dá vontade de sonhar com uma infraestrutura autossuficiente
  • Fico curioso sobre onde dá para ver as estatísticas exatas de uptime do Cloudflare atualmente
  • Ainda assim, comparar simplesmente um PC pessoal com o Cloudflare é uma analogia sem sentido

• Numa escala como a do Cloudflare, é obrigatório existir um ambiente de testes.
  Toda mudança deveria ser simulada num ambiente-modelo isolado antes de ser implantada gradualmente.
  Mais importante do que um sistema de tipos forte são as proteções processuais

  • Na nossa empresa usamos um esquema de deploy em três etapas: desenvolvimento → integração interna → produção.
    Equipes que erram muito andam mais devagar, e equipes mais confiáveis avançam mais rápido.
    No fim, velocidade técnica é uma questão de escolha. Se houver risco ao SLA, é preciso reduzir a velocidade e reforçar os testes
  • Também dá para usar os usuários gratuitos como test bed e oferecer a versão estável aos clientes pagos
  • Quando se diz que “um sistema de tipos forte não vai te salvar”, o sentido é que, diante de uma falha processual, a linguagem fica impotente

• Parece que a qualidade de software do Cloudflare está vacilando.
  Houve até um bug em que a validação de acesso de uma função exclusiva para enterprise só era feita na etapa final

  • Eu também já passei por uma configuração sem possibilidade de rollback na API do Cloudflare.
    Só dava para alterar passando pelo suporte, e a correção levou dias
    Link do caso relacionado
  • Acho possível que esse tipo de bug tenha vindo de código escrito por IA
  • Gostaria de ouvir com mais detalhes o que exatamente significa “só verifica na etapa final”

• Tenho curiosidade sobre a cultura operacional do Cloudflare.
  Houve um erro durante a resposta a um problema de segurança, e mesmo assim fizeram outro deploy global em vez de rollback — uma decisão arriscada.
  Isso equivale a violar o princípio básico de “na dúvida, faça rollback”

  • Mas desta vez era uma situação urgente, como resposta à vulnerabilidade React Server RCE.
    Se atrasassem o deploy, clientes poderiam de fato ser hackeados, então era um caso em que velocidade era segurança
  • Rollback nem sempre é a resposta certa. Se o procedimento não é familiar, ele próprio vira um risco
  • Na verdade, os dois deploys eram de componentes diferentes.
    A primeira correção acabou revelando um bug latente na segunda, então às vezes roll forward é mais realista do que rollback
  • É bem possível que o Cloudflare tenha acumulado dívida técnica ao longo do crescimento acelerado.
    As falhas frequentes recentes podem ser um sinal de que essa dívida está aparecendo