Na manhã de 5 de dezembro de 2025, uma outage (queda) global da Cloudflare derrubou, por alguns minutos, partes importantes da web. Serviços gigantes como Zoom, LinkedIn, Coinbase e Canva ficaram instáveis ou exibiram erros, não porque a Cloudflare tenha sido invadida, mas porque ela tropeçou na própria defesa: uma mudança emergencial no WAF (Web Application Firewall) para mitigar o React2Shell acabou provocando a indisponibilidade que pretendia evitar.
A ironia é dura e, para times de SRE, familiar: quando a ameaça é crítica, a pressão para “corrigir agora” aumenta, e o risco operacional das mudanças sobe junto. Neste caso, o “remédio” aplicado para bloquear um exploit de RCE (Remote Code Execution) em React foi potente demais, e o paciente desmaiou.
O que aconteceu, em poucas linhas
O incidente começou por volta de 08:47 UTC e foi resolvido perto de 09:12 UTC, totalizando cerca de 25 minutos de impacto. Na prática, muitas requisições passaram a receber HTTP 500, o tipo de erro que, para o usuário, parece “a internet quebrou”.
A própria Cloudflare explicou que a falha foi disparada por uma mudança ligada à forma como seu WAF analisava (parse) requisições. O detalhe técnico é o que transforma a história em “manual de lições” para resposta a incidentes: a alteração não era para adicionar um recurso novo ou otimizar performance, mas para aumentar a proteção contra um CVE recém-divulgado e possivelmente já em exploração.
React2Shell: a ameaça por trás do caos
O pivô do episódio é o React2Shell, nome dado pela comunidade à vulnerabilidade CVE-2025-55182. Em termos simples, trata-se de uma falha crítica de RCE não autenticada: um atacante remoto consegue fazer o servidor executar código a partir de requisições cuidadosamente montadas, sem precisar de login.
O alerta público veio em 3 de dezembro de 2025, com recomendação de atualização imediata. O problema está ligado ao ecossistema de React Server Components e ao modo como payloads são decodificados em endpoints de “server functions”. Algumas versões do React 19 foram listadas como afetadas e, em seguida, corrigidas em releases de patch.
O que elevou o senso de urgência foi a expectativa (e evidência) de exploração rápida. Em 5 de dezembro, a CISA incluiu a CVE-2025-55182 no catálogo de vulnerabilidades conhecidamente exploradas (KEV), um sinal institucional forte de que o risco não era hipotético. Paralelamente, fornecedores e nuvens publicaram orientações e regras gerenciadas de WAF para “ganhar tempo” enquanto as equipes aplicavam patches, porque WAF não elimina a vulnerabilidade, apenas tenta bloquear algumas formas de exploração.
O remédio amargo: como um ajuste de WAF virou negação de serviço
Para entender o acidente, vale uma analogia direta.
Pense no WAF como o “porteiro com detector de metais” na entrada de um prédio: ele não conserta o que existe dentro do prédio, só tenta impedir que algo perigoso entre. Quando surge uma ameaça crítica como o React2Shell, a tendência é aumentar a sensibilidade do detector rapidamente. O risco é que, ao ficar sensível demais, ele começa a barrar pessoas comuns e trava a fila.
Segundo o post-mortem oficial, a Cloudflare estava ampliando o “buffer” de inspeção para 1 MB, alinhado ao limite padrão aceito por aplicações Next.js, para melhorar a cobertura de detecção contra a CVE-2025-55182. Em paralelo, ela identificou erros em uma ferramenta interna usada para testar e refinar regras novas de WAF e decidiu desativar essa parte do sistema.
Aqui entra o ponto de alto risco operacional: essa desativação foi feita via um sistema global de configuração que se propaga em segundos pela rede toda, diferente de um rollout gradual com validação de saúde. Em uma das versões antigas do proxy (a Cloudflare cita o ambiente “FL1”), esse caminho levou a um estado de erro que resultou em respostas HTTP 500.
O componente mais didático do relato é o “como” da falha: um mecanismo de “killswitch” (feito para desligar regras problemáticas rapidamente) foi aplicado a uma regra cujo tipo de ação era execute, usada para chamar a avaliação de outro conjunto de regras. Esse cenário específico, desativar uma regra do tipo “execute”, não tinha sido exercitado antes naquele stack legado. O resultado foi um erro de runtime (em Lua) ao tentar acessar um objeto que não existia porque a execução havia sido pulada.
A Cloudflare também esclareceu que, na arquitetura mais nova (proxy “FL2”, escrito em Rust), esse erro não ocorreu, reforçando um ponto clássico de SRE: sistemas antigos carregam “armadilhas” silenciosas, e uma mudança emergencial pode acionar exatamente o canto do código que ninguém tocava há anos.
O dilema da segurança: proteger ou derrubar?
O dilema não é moral, é matemático, e todo mundo que opera infraestrutura conhece: quando a ameaça tem severidade máxima, o “tempo para mitigar” precisa cair para minutos. Só que, quando você move rápido na camada mais central do tráfego, você aumenta o blast radius de um erro.
A resposta da Cloudflare ilustra o conflito entre dois reflexos válidos:
- Corrigir rápido: bloquear exploração em massa enquanto milhares de times ainda estão identificando versões e aplicando patches no React e no Next.js.
- Testar bem: garantir que uma mudança global não crie um incidente maior do que aquele que se tenta evitar.
No papel, “testar bem” é inegociável. Na prática, quando há exploração ativa, o cronômetro corre. A Cloudflare, inclusive, reconheceu o agrupamento de incidentes (este e o de novembro) como inaceitável e descreveu iniciativas para reduzir riscos, como rollouts mais seguros para configurações, melhorias de “break glass” e postura de “fail-open” em cenários específicos, para evitar que um erro de config derrube a rede inteira.
Há também uma lição de arquitetura: “segurança como dado”. Regras de WAF, políticas e configs têm impacto equivalente a “código” quando são interpretadas no dataplane. Se você consegue derrubar o mundo com uma configuração, então configuração é tão crítica quanto binário, e precisa de guardrails do mesmo nível: canary, validação automática, rollback rápido e limites de blast radius.
O que isso ensina para SRE, times de segurança e quem depende de WAF
Algumas lições práticas ficam quase inevitáveis:
- Modo de pré-visualização e telemetria antes de bloquear
Fornecedores como Google Cloud enfatizaram que regras de WAF devem, quando possível, começar em modo de “preview/log-only” para medir falsos positivos e impacto. Em emergências, nem sempre dá para esperar horas, mas dá para reduzir risco com canários e amostragens, nem que seja por poucos minutos. - Configuração global também precisa de rollout gradual
Quando um plano de mitigação usa um mecanismo que “bate em tudo ao mesmo tempo”, um erro vira incidente global. A diferença entre “gradual” e “instantâneo” não é detalhe, é a fronteira entre degradação e apagão. - Separar ferramentas internas do caminho de produção
A cadeia causal envolveu desativar um mecanismo de teste interno. Quando uma ferramenta interna compartilha componentes críticos com produção, qualquer “desliga isso rápido” vira uma possível bomba-relógio. - Fail-open versus fail-closed precisa ser decisão consciente
Em segurança, “falhar fechado” parece mais seguro, mas pode transformar bugs em negação de serviço. O ideal é escolher explicitamente onde falhar fechado faz sentido e onde a continuidade precisa vencer, com caminhos de fallback bem estudados. - Plano de continuidade para dependências concentradas
Quando muitos serviços “colocam ovos na mesma cesta”, uma falha vira cascata. Multi-CDN, bypass planejado, rotas alternativas e degradar funcionalidades são chatos, caros e politicamente difíceis, até o dia em que viram a diferença entre “incidente” e “pânico”.
O que fazer agora (se você roda React ou Next.js)
Para quem está do lado “cliente do mundo”, a ordem de prioridade continua clara:
- Patch primeiro: WAF ajuda, mas não substitui atualização e validação.
- Inventarie onde existe RSC/server functions: o risco real está no uso do stack vulnerável, não no nome “React” no frontend.
- Use WAF como camada temporária: regras gerenciadas compram tempo, e telemetria indica tentativas de exploração, mas o destino final é corrigir dependências e redesenhar exposição quando necessário.
