Última falha global da Cloudflare: O que deu errado e o que significa para seu site

No dia 5 de dezembro de 2025, o Cloudflare - um dos pilares fundamentais da Internet moderna - sofreu mais uma avaria grave que interrompeu, por breves instantes, grandes partes da Web. Para os proprietários de sítios, as equipas SRE e os utilizadores habituais, foi um lembrete claro de como a nossa Internet "sempre ligada" é realmente frágil.

Abaixo está um mergulho profundo no que aconteceu, porque é importante e que lições as equipas de infra-estruturas e aplicações podem tirar daí.

Recapitulação rápida: o que aconteceu a 5 de dezembro de 2025?

Na manhã de 5 de dezembro de 2025, a Cloudflare sofreu uma interrupção de serviço global que fez com que muitos sites retornassem páginas em branco ou de erro por vários minutos. A interrupção afetou uma ampla gama de serviços importantes, incluindo plataformas como LinkedIn, Zoom, Coinbase, Canva, Groww, BookMyShow e outros, dependendo da região e do peering. NotíciasAP+1

As redacções e os sítios de monitorização relataram:

• Os utilizadores vêem "páginas vazias" em vez de conteúdo normal quando visitam os sites afectados. Sky News+1

• Um pico de erros 5xx e problemas de conetividade em sites e APIs que dependem da rede de borda do Cloudflare. Search Engine Journal

• Problemas não só com o tráfego dos clientes, mas também com o painel de controlo e as API da Cloudflare, o que reduziu a observabilidade e o controlo precisamente quando os clientes mais precisavam. AP News+1

Embora a interrupção tenha durado apenas um curto período de tempo - cerca de 08:47 a 09:13 GMT, de acordo com os primeiros relatórios - o raio da explosão foi grande o suficiente para afetar brevemente plataformas críticas, como Coinbase e Claude AI da Anthropic, e fez com que as ações da própria Cloudflare caíssem cerca de 4-4,5% no pré-mercado. Reuters+1

A Cloudflare declarou que:

• O incidente não foi causado por um ataque cibernético.

• O incidente não foi causado por um ataque cibernético, mas sim por uma mudança interna no tratamento/processamento de pedidos do firewall em resposta a uma vulnerabilidade recentemente divulgada do React Server Components (RSC). Reuters+1

Por outras palavras: uma alteração de segurança na lógica da firewall da Cloudflare introduziu um efeito secundário que tornou temporariamente indisponível uma grande parte da sua rede.

O que é que se avariou exatamente?

Do ponto de vista do utilizador, houve dois sintomas dominantes:

1. Os principais sítios Web apresentavam páginas de erro ou em branco

   • Um grande número de sítios apresentou erros HTTP 5xx, ou simplesmente páginas vazias/brancas sem conteúdo. Sky News+1

   • Para algumas plataformas, isso significava que as páginas de login não eram carregadas, os painéis não eram renderizados ou as APIs não eram executadas.

2. O plano de controlo da própria Cloudflare estava degradado

   • O Cloudflare Dashboard e as APIs relacionadas também foram afetadas, limitando a capacidade dos clientes de alterar as configurações ou ver o que estava acontecendo em tempo real. AP News+1

A nível técnico, as primeiras declarações da Cloudflare e os relatórios dos media apontam para uma alteração na forma como a firewall processava os pedidos, introduzida para mitigar uma vulnerabilidade nos componentes do React Server. Essa alteração fez com que a rede da Cloudflare deixasse de servir corretamente o tráfego durante vários minutos. Reuters+1

Mesmo uma breve interrupção num fornecedor que está à frente de tantos sites cria um padrão de falha em cascata:

• Os navegadores tentam novamente as ligações, aumentando a carga.

• Os backends dependentes registam picos, acumulação de filas ou tempos limite.

• As ferramentas de monitoramento rapidamente inundam os engenheiros de plantão com alertas, muitas vezes com dados incompletos ou enganosos porque a própria pilha de observabilidade também pode depender do Cloudflare.

Por que essa interrupção se destaca: "segundo grande incidente em três semanas"

Esta não foi uma falha isolada. Ocorreu menos de três semanas após um incidente anterior da Cloudflare, muito maior, em 18 de novembro de 2025.

3.1 A interrupção de 18 de novembro de 2025 (contexto)

Em 18 de novembro de 2025, a Cloudflare sofreu uma grande interrupção que:

• Causou erros 5xx generalizados e degradou o desempenho de muitos sites em todo o mundo.

• Impactou plataformas de alto perfil, incluindo X (antigo Twitter) e OpenAI / ChatGPT, entre outras. Decodo

• Foi rastreado até um bug na lógica de geração de um arquivo de recurso de gerenciamento de bots, que afetou muitos dos principais serviços da Cloudflare. O Blogue Cloudflare+1

Mais tarde, a Cloudflare publicou um post-mortem detalhado, explicando que o ficheiro de configuração Bot Management causou falhas em cascata nos sistemas internos - um caso clássico de um único artefacto de configuração com comportamento incorreto que faz cair caminhos de tráfego críticos. Blogue da Cloudflare

3.2 5 de dezembro vs 18 de novembro: padrão semelhante, gatilho diferente

Comparando os dois:

• 18 de novembro de 2025

  • Gatilho: Bug na geração de ficheiros de funcionalidades de gestão de bots. O Blogue Cloudflare+1

  • Efeito: Erros 5xx amplos, problemas no pipeline de configuração, interrupção global.

• 5 de dezembro de 2025

  • Gatilho: Mudança no tratamento do firewall implementada como uma mitigação para uma vulnerabilidade dos componentes do React Server. Reuters+1

  • Efeito: indisponibilidade breve mas alargada, páginas em branco, problemas no painel de controlo/API do Cloudflare.

Para os clientes, a distinção não é importante: ambos os incidentes foram interrupções clássicas conduzidas pelo plano de controlo, em que uma alteração de configuração ou segurança ao nível do fornecedor teve consequências em todo o sistema.

Um padrão que vai para além da Cloudflare

A Cloudflare não está sozinha neste caso. Ao longo dos últimos anos, assistimos a uma série de interrupções à escala da Internet causadas por erros de configuração, actualizações de software ou mitigações de segurança nos principais fornecedores:

• A Cloudflare, a Microsoft, a Amazon e a CrowdStrike registaram incidentes que se propagaram a milhares de serviços dependentes. Reuters+1

• Uma análise das interrupções da Internet assinala dezenas de interrupções globais significativas apenas na primeira metade da década de 2020, sublinhando o risco crescente de concentração que representa a dependência de um pequeno conjunto de fornecedores de infra-estruturas. TrueSolvers

Esta última avaria do Cloudflare insere-se num tema mais vasto:

Quanto mais centralizamos a segurança, o DNS, a CDN e a computação de ponta num punhado de fornecedores, mais um único erro de configuração se pode tornar um risco sistémico para toda a Internet.

Lições técnicas do mau funcionamento de 5 de dezembro

Da limitada informação pública, podemos já extrair várias lições técnicas que são relevantes para as equipas SRE, DevOps e de plataformas.

5.1 As alterações de segurança necessitam da mesma disciplina que as implementações de código

A causa principal foi uma alteração no processamento de pedidos de firewall implementada como parte da atenuação de uma vulnerabilidade dos componentes do React Server. Reuters+1

Principais conclusões:

• Correções de segurança = alterações de produção
  As atualizações de configuração orientadas à segurança devem passar pelo mesmo rollout, testes e guardrails que as alterações regulares de recursos. "É um patch de segurança" não é uma justificação para contornar os controlos normais.

• Implementação faseada e controlos de raio de explosão
  Qualquer alteração ao comportamento global da firewall deve ser:

  • Implementada primeiro num subconjunto de POPs ou clientes.

  • Protegida por sinalizadores de recursos e mecanismos de reversão instantânea.

  • Monitorizada com métricas canárias específicas (por exemplo, taxas 5xx, TTFB, rácios de páginas vazias) para detetar falhas em segundos.

5.2 A robustez do plano de controlo é tão crítica como o tempo de funcionamento do plano de dados

O facto de o painel de controlo e as API da Cloudflare também terem sofrido uma degradação durante o incidente é especialmente doloroso. AP News+1

Para os operadores, isso significa:

• Você precisa de maneiras fora da banda ou independentes do provedor para:

  • Mudar o DNS.

  • Contornar ou desativar camadas com falhas (por exemplo, ir temporariamente direto para a origem).

  • Acessar logs e métricas, mesmo que a UI/API do próprio provedor esteja offline.

Se a sua única maneira de corrigir um problema depende da mesma infraestrutura que está atualmente quebrada, você perdeu uma rede de segurança crítica.

5.3 Os artefactos de configuração podem ser tão perigosos como o código

Tanto os incidentes de 18 de novembro como os de 5 de dezembro tinham o mesmo padrão estrutural:

• Um artefacto de configuração ou política (ficheiro de gestão de bots / comportamento de regra de firewall)

• Implementado através de automação global

• Interagindo mal com o tráfego de produção em escala. Blogue da Cloudflare+2Decodo+2

A lição: tratar a configuração com o mesmo rigor que o código:

• Controle de versão, revisões de código e testes.

• Validação em relação a replays de tráfego realistas no staging.

• Limitar o raio de ação de uma única configuração errada.

O que isso significa para as empresas que dependem da Cloudflare

A maioria das organizações não pode simplesmente "deixar de usar a Cloudflare". Ela está profundamente integrada a:

• DNS e roteamento anycast

• Proteção DDoS

• WAF e gestão de bots

• CDN e cache

• Acesso de confiança zero, WARP, Workers, Workers AI e muito mais. Blogue da Cloudflare

Mas você pode reduzir o impacto de futuros problemas de funcionamento.

6.1 Mapeie sua dependência da Cloudflare

Primeiro, saiba como você depende da Cloudflare:

• O seu DNS reside inteiramente lá?

• Termina o TLS apenas na Cloudflare ou também na origem?

• As APIs críticas são acessíveis publicamente apenas via Cloudflare?

• As equipes internas dependem do Cloudflare Tunnel/Acess/WARP para acessar serviços confidenciais?

Durante a interrupção de 12 de junho de 2025, por exemplo, a Cloudflare observou que produtos como Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile, Zaraz e partes do Dashboard foram afetados - um lembrete de quantas camadas podem estar vinculadas a um único fornecedor. Blogue da Cloudflare

6.2 Planejar failover de DNS e CDN

Para serviços de alto valor, considere:

• DNS secundário com outro provedor capaz de assumir o controle rapidamente.

• Estratégias de várias CDNs ou CDN-bypass, para que, se a Cloudflare falhar, você possa:

  • Direcionar o tráfego diretamente para a origem.

  • Ou transferir o tráfego para uma CDN de backup, mesmo que o desempenho seja temporariamente pior.

Isso raramente vem de graça (custo/complexidade), mas para serviços de missão crítica pode valer a pena a resiliência.

6.3 Crie resiliência no nível do aplicativo

Mesmo quando a borda está quebrada, seu aplicativo pode falhar mais graciosamente:

• Sirva páginas de erro estáticas em cache que expliquem a situação em vez de respostas em branco.

• Crie uma lógica de repetição do lado do cliente que recue, em vez de martelar uma borda em dificuldades.

• Desacoplar funcionalidades não críticas (análises, scripts de terceiros, personalização pesada) para que possam ser desactivadas rapidamente.

6.4 Operacionalmente: tratar as interrupções do fornecedor como cenários normais de um dia de jogo

Utilize esta interrupção e a de 18 de novembro como material para os dias de jogo:

• Com que rapidez você pode detetar que o problema é com o Cloudflare em vez de sua própria origem?

• Os runbooks de plantão incluem:

  • Links para a página de status do Cloudflare e os caminhos de contato do seu fornecedor? Status do Cloudflare+1

  • Etapas pré-aprovadas para contornar ou redirecionar o tráfego?

• Você está monitorando verificações externas que atingem seu serviço sem passar pelo Cloudflare?

Como a Cloudflare provavelmente responderá

A Cloudflare tem um longo histórico de publicação de post-mortems detalhados para grandes incidentes (por exemplo, os incidentes de 20 de junho de 2024 e 27 de junho de 2024, bem como as interrupções de 12 de junho de 2025 e 18 de novembro de 2025 ). OBlogueda Cloudflare+3O Blogueda Cloudflare+3O BloguedaCloudflare+3

Com base nesse padrão, podemos esperar razoavelmente:

• Um post técnico no blogue explicando:

  • A alteração exata da lógica do firewall.

  • Por que a mitigação da vulnerabilidade dos componentes do servidor React se comportou de forma inesperada.

  • Quanto tempo durou o impacto em diferentes regiões.

• Uma lista de correções, como:

  • Validação e teste de configuração mais fortes.

  • Implementações faseadas mais rigorosas e accionadores de reversão automatizados.

  • Melhor separação entre os sistemas que atendem ao tráfego de clientes e aqueles que alimentam o painel e as APIs.

Para os clientes, essa transparência é valiosa, mas não elimina a necessidade de projetar a falha do provedor em suas próprias arquiteturas.

O panorama geral: centralização versus resiliência

O mau funcionamento de 5 de dezembro faz parte de uma conversa mais ampla que a indústria já está a ter:

• Centralizamos enormes quantidades de roteamento, DNS, segurança, WAF e entrega de conteúdo em um punhado de provedores. TrueSolvers+1

• Cada incidente grave na Cloudflare, Azure, AWS ou CrowdStrike comporta-se agora como um choque no sistema financeiro: não só derruba um site, como também afecta brevemente toda a economia digital.

Para os reguladores e as grandes empresas, isso levanta questões sobre:

• Risco de concentração - até que ponto as infra-estruturas críticas devem ser obrigadas a ter redundância de vários fornecedores?

• Transparência e responsabilidade - com que rapidez e clareza é que os fornecedores partilham os pormenores sobre as causas?

• Investimento em resiliência - estamos a gastar o suficiente em protecções em vez de no envio de novas funcionalidades?

Resumo

Para concluir, o último grande mau funcionamento do Cloudflare em 5 de dezembro de 2025 pode ser resumido como:

• Uma interrupção global, mas breve, causada por uma alteração no processamento do firewall interno implementada como parte de uma resposta de segurança.

• Visível para os utilizadores como páginas em branco e erros 5xx nos principais sites, e degradação do painel de controlo e das APIs da Cloudflare.

• O segundo incidente significativo em menos de três semanas, após a interrupção muito maior de 18 de novembro de 2025 relacionada ao gerenciamento de bots.

• Outro ponto de dados na história contínua de risco de concentração de infraestrutura, em que erros de configuração em alguns provedores podem interromper brevemente a Internet para todos.

Para as empresas que dependem do Cloudflare, a mensagem principal não é "entrar em pânico e migrar", mas sim:

Parta do princípio de que os seus fornecedores irão falhar e conceba a sua arquitetura, operações e processos empresariais de modo a que uma avaria de curta duração não se transforme numa crise existencial.