Outage da Cloudflare expõe risco de regex no WAF global

A Cloudflare atribuiu a instabilidade global desta terça-feira a uma regra mal configurada no Web Application Firewall, o WAF, implantada durante uma atualização rotineira de regras gerenciadas.¹ O resultado foi visível para clientes e usuários finais: erros 502 em domínios proxied pela rede, queda de tráfego e uma investigação emergencial sobre consumo de CPU.

O ponto técnico é direto. Uma expressão regular usada para melhorar a detecção de JavaScript inline em ataques fez CPUs chegarem a 100% em máquinas da rede mundial. Mesmo em modo de simulação, no qual a regra registra comportamento sem bloquear tráfego de clientes, o código precisa ser executado. Quando essa execução consome CPU demais, a diferença entre observar e derrubar produção desaparece.

Regex também é código de produção

Expressões regulares costumam ser tratadas como configuração, mas em um WAF global elas são parte do caminho crítico de requisições HTTP e HTTPS. Uma regra ruim não falha apenas no painel de segurança. Ela compete por CPU com proxy, CDN e demais funções que mantêm sites acessíveis.

Esse é o alerta mais importante para times de plataforma. Mudanças pequenas podem ter impacto sistêmico quando rodam em todos os pontos de presença, para todo o tráfego, em segundos. O risco não está apenas no tamanho do diff, mas no local onde ele será executado e na quantidade de requisições que passará por ele.

Velocidade global exige rollout progressivo

A Cloudflare informou que a regra foi implantada globalmente de uma vez, diferente do processo progressivo usado em outros tipos de software da empresa.² A justificativa operacional é compreensível: regras de WAF precisam responder rápido a ataques emergentes. Mas rapidez sem freios transforma defesa em vetor de indisponibilidade.

O desenho correto não é impedir mudanças urgentes. É separar emergência real de atualização comum, testar consumo de CPU, executar canary, medir degradação e manter rollback simples. Em segurança, o tempo de reação importa. Em disponibilidade, o raio de impacto importa tanto quanto.

A própria infraestrutura entra no incidente

Incidentes em provedores de borda têm um agravante: clientes, painéis internos, APIs e ferramentas de resposta podem depender da mesma infraestrutura afetada. Quando o provedor usa seus próprios serviços para autenticação, observabilidade ou operação, a recuperação precisa prever caminhos alternativos.

Para empresas que dependem de CDN, WAF e proteção DDoS, o episódio reforça uma lição pragmática. Terceirizar borda reduz muito trabalho operacional, mas não elimina gestão de risco. É necessário entender planos de contingência, status page, bypass, cache, DNS, comunicações e dependências internas.

A falha não foi um ataque, segundo a própria Cloudflare. Foi uma mudança de produção com efeito global. Isso torna o caso ainda mais relevante para engenharia: a maioria das interrupções graves nasce de sistemas fazendo exatamente aquilo que foram autorizados a fazer, só que sem limites suficientes.