Cloudflare 2019: O Regex que Derrubou uma Rede Global

Em 2 de julho de 2019, às 13h42 UTC, a Cloudflare realizou um deploy de novas regras para seu WAF gerenciado. Entre as regras estava a 100137, destinada a detectar ataques XSS. O regex central da regra era:

(?:(?:"|'|\]|\[|\\|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||&&)*(?:[0-9]{0,4}d?(?:x|xx|xxx|xxxx)?)(?:;|\\|,|\+|\-|\*|\/|%|&|\||\^|<|>|=|!)))+

O problema está no grupo ((?:\s|-|~|!|{}|\|\||&&)*) combinado com o quantificador externo +. Esse padrão cria o que a teoria da computação chama de backtracking catastrófico: para uma string que não casa com o padrão mas que é longa o suficiente, o motor de regex tenta exponencialmente mais combinações antes de desistir. O tempo de execução deixa de ser O(n) e passa a ser O(2ⁿ) em relação ao comprimento da entrada.

A Cloudflare utilizava a engine de regex do Lua (baseada em PCRE — Perl Compatible Regular Expressions), que não possui proteção nativa contra esse comportamento. Ao contrário de engines baseadas em autômatos finitos (como RE2 ou Rust's regex crate), o PCRE realiza backtracking sem limite de tempo por padrão.

Cada requisição HTTP processada pelo WAF passou a consumir 100% de um core de CPU pelo tempo que durasse a tentativa de matching. Com tráfego real chegando a centenas de milhares de requisições por segundo em cada PoP, todos os cores de todos os servidores em todos os data centers foram saturados quase instantaneamente. O sistema de proteção contra DDoS da própria Cloudflare — que depende dos mesmos processos NGINX — parou de funcionar. O tráfego legítimo foi descartado junto com o malicioso.

Este incidente é pedagogicamente valioso precisamente porque a Cloudflare tinha controles de qualidade. A regra passou por revisão de código humana. Passou por uma suíte de testes automatizados. Passou por um ambiente de staging. E ainda assim chegou à produção global com um padrão catastrófico. Por quê?

Revisão de código humana é eficaz para lógica de negócio, mas detectar backtracking catastrófico em regex requer conhecimento especializado em teoria de autômatos que não é universalmente distribuído entre engenheiros. O regex parecia razoável à inspeção visual — ele cobria os casos de XSS pretendidos nos testes de exemplo.

Testes automatizados validaram que a regra funcionava — que ela detectava os payloads XSS para os quais foi projetada. Mas os testes não incluíam casos de borda patológicos: strings longas que quase casam mas não casam, que são exatamente as entradas que maximizam o backtracking. Esse é um gap clássico: testar o caminho feliz não é suficiente para sistemas de segurança que processam input adversarial.

Staging replicava a configuração de produção, mas não replicava o volume de tráfego. Com poucas requisições por segundo, mesmo um regex patológico pode não ser observável — o impacto só se torna visível sob carga real. Isso é uma armadilha comum em testes de performance: o ambiente de staging raramente tem a pressão necessária para revelar problemas de complexidade algorítmica.

Deploy global simultâneo foi a decisão arquitetural que transformou um bug em uma catástrofe. Se a Cloudflare tivesse feito um staged rollout — começando com 1% dos PoPs, observando métricas de CPU por 5 minutos, e só então progredindo — o impacto teria sido contido. A ausência de staged rollout para mudanças de WAF é surpreendente dado o histórico da indústria com deploys graduais. A justificativa implícita provavelmente era velocidade de resposta a ameaças: quando você descobre um novo vetor de ataque, quer proteção global imediata. Mas essa velocidade tem um custo de risco que este incidente quantificou de forma dolorosa.

A Cloudflare publicou um post-mortem detalhado e implementou um conjunto substancial de mudanças. Analiso cada uma com o olho de quem já operou sistemas de borda em escala financeira:

1. Substituição do motor de regex (PCRE → RE2/Rust)

A mudança mais importante. RE2 e a crate regex do Rust garantem complexidade O(n) para qualquer expressão regular, eliminando a possibilidade de backtracking catastrófico por construção. Isso não é uma mitigação — é uma eliminação da classe de falha. O trade-off é que RE2 não suporta alguns recursos do PCRE (lookahead negativo, backreferences), o que pode requerer reescrita de regras existentes. Para um WAF, esse trade-off é claramente favorável: previsibilidade de performance supera expressividade de regex.

2. Análise estática de complexidade no CI

Ferramentas como rxxr2 ou análise de complexidade de regex baseada em teoria de autômatos foram adicionadas ao pipeline. Qualquer regex que possa exibir comportamento super-linear é rejeitado antes do merge. Isso é defense-in-depth correto: não confiar apenas na revisão humana para propriedades que podem ser verificadas automaticamente.

3. Staged rollout obrigatório para mudanças de WAF

Deploys de regras agora seguem um processo de rollout gradual: um subconjunto de PoPs primeiro, com observação automática de métricas de CPU e latência, antes de progressão global. Isso é o padrão correto para qualquer mudança que afete o caminho crítico de processamento de tráfego.

4. Limite de CPU por operação de regex

Mesmo com RE2, um timeout por operação de WAF foi adicionado como camada adicional de proteção. Se uma operação excede um threshold de tempo, ela é abortada e a requisição é passada (fail-open) ou bloqueada (fail-closed) conforme a política configurada. Isso é defense-in-depth: múltiplas camadas independentes.

5. Melhoria dos casos de teste

A suíte de testes foi expandida para incluir inputs patológicos: strings longas, strings que quase casam, strings com repetição de caracteres. Isso deveria ter existido desde o início para um sistema que processa input adversarial.

O conjunto de mudanças é exemplar. A Cloudflare não apenas corrigiu o sintoma (a regra específica) mas atacou a causa raiz em múltiplas camadas: a engine, o processo de deploy, o pipeline de CI e os testes. Isso é como um post-mortem bem executado deve resultar em ação.