# Uma regex derrubou a Cloudflare. 27 minutos.

Published: 2026-09-12

2 de julho de 2019, 13:42 UTC: uma nova regra para o Web Application Firewall da Cloudflare entra em vigor em mais de 180 cidades em cerca de dois segundos. É uma regra XSS em modo de simulação, então não bloqueia nada, mas ainda assim é executada em cada solicitação e termina em .\*(?:.\*=.\*). O PCRE faz backtracking, cada núcleo de CPU que atende requisições HTTP atinge 100%, e cada site com proxy Cloudflare retorna 502 por 27 minutos; o tráfego cai 82%. O "kill switch" está atrás do Cloudflare Access, que está atrás da Cloudflare. Postmortem, do próprio relatório da Cloudflare: o "CPU guard" removido semanas antes em uma refatoração destinada a economizar CPU, o procedimento que permitiu que qualquer regra pulasse o "staging", o motor sem garantia de complexidade, as 11 causas e as 7 correções. Veredito sobre a correção: SHIP IT.

Canonical: https://thedailydiff.dev/pt-BR/video/2026-09-12-cloudflare-regex/

## O que este vídeo aborda

- 13:31–13:42 UTC: PR mesclado, CI verde (sem teste de CPU), Quicksilver envia a regra para mais de 180 cidades; as regras WAF pulam as fases DOG → PIG → Canary
- 13:45–14:07: primeira página; CPU 100% em todo o mundo, tráfego -82%, 502s em todos os lugares; o painel de controle interno está atrás do Cloudflare Access, que está fora do ar; algumas credenciais expiraram; um bypass raramente testado
- 14:07–14:09: término global do WAF; tráfego e CPU normais após 27 minutos; 14:52 WAF de volta menos a regra
- 2 de julho (15:50 UTC) e 12 de julho: Cloudflare publica a nota do mesmo dia e o postmortem completo; "CPU guard" readicionado, 3.868 regras relidas, "rollouts" em fases, migração para um motor de regex de tempo linear

## Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

0:00 Uma expressão regular entra em vigor em cada servidor Cloudflare de uma vez, e pelos próximos vinte e sete minutos os sites atrás dela são uma página 502, que, para um firewall, é a configuração mais rigorosa possível. 2 de julho de 2019, 13:42 UTC. A Cloudflare posta em duas horas: não é um ataque, um deploy ruim, tráfego 82% menor. Dez dias depois, o CTO John Graham-Cumming publica o postmortem completo, regex incluída, e o Hacker News dá 698 pontos,

0:26 o que para uma interrupção é uma ovação de pé. Como acontece, por que é possível e quem realmente leva a culpa. Este é o The Daily Diff, postmortem. 13:31. Um "pull request" é mesclado: uma nova regra de firewall contra "cross-site scripting", em modo de simulação, então não bloqueia nada. 13:37, testes passam; nenhum mede a CPU. 13:42, a regra é enviada para 180 cidades em dois segundos, porque as regras WAF pulam as fases "dog", "pig" e "canary" que outras releases recebem.

0:54 13:45, a primeira página. 13:49, o Hacker News tem um tópico na página de status, que ainda diz que todos os sistemas estão operacionais. A regra termina em ponto-asterisco, ponto-asterisco, igual, ponto-asterisco: qualquer coisa, depois qualquer coisa, depois um sinal de igual. O PCRE tenta avidamente, falha e faz "backtracking" através de cada outra divisão. x igual a x leva 23 passos. Vinte x's depois do igual: 555.

1:15 Vinte x's, sem sinal de igual: 4.067 passos para não encontrar nada. Execute isso em cada requisição e cada núcleo estará a cem por cento, não fazendo nada, completamente. Dois guardas deveriam ter percebido. O limite de CPU nas regras foi removido por engano semanas antes, em uma refatoração destinada a fazer o WAF usar menos CPU. E o procedimento permite que qualquer regra pule o "staging", porque as regras existem para parar ataques em tempo real; esta não era uma emergência, e mesmo assim foi global.

1:37 14:00, o WAF é identificado; nenhum ataque. 14:02, alguém propõe o término global: um componente, desligado, em todo o mundo. O switch está atrás do Cloudflare Access. O Cloudflare Access está atrás da Cloudflare. Algumas credenciais expiraram por desuso, então a rede mais rápida da internet gasta cinco minutos em um "bypass" que ninguém treinou. 14:07, "kill". 14:09, tráfego normal. git blame: um "rollout" com uma velocidade, global; um "CPU guard" refatorado por

2:04 acidente; um motor de regex sem limite superior. Não o engenheiro que escreveu a regra: o postmortem lista onze causas e não nomeia ninguém. Raio de explosão: 27 minutos, 82 por cento do tráfego, 100 por cento de CPU em cada núcleo, em cada cidade. O painel e a API estão atrás da mesma borda, então os clientes não podem nem mesmo desligar isso. Hacker News, sob o postmortem: eles tinham um problema, usaram uma expressão regular, agora têm dois. Piada antiga. Ainda compila.

2:28 Veredito, postmortem: SHIP IT. O "CPU guard" está de volta, todas as 3.868 regras são lidas manualmente, as regras passam por "staging", e o motor muda para um com garantias de tempo linear, publicado por Ken Thompson em 1968. Segunda-feira: sem ponto-asterisco ponto-asterisco em qualquer coisa que seja executada por requisição, e mantenha o "kill switch" longe do que ele mata. Envie-me o incidente sobre o qual você ainda não tem permissão para falar, nos comentários, ou em the daily diff dot dev.

2:53 E essa é a diferença de hoje. Eu sou o Niko da Axrisi. Mescle com responsabilidade.

## Fontes

- [John Graham-Cumming, "Details of the Cloudflare outage on July 2, 2019" (Jul 12, 2019)](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/) — blog.cloudflare.com
- [Matthew Prince, "Cloudflare outage caused by bad software deploy (updated)" (Jul 2, 2019)](https://blog.cloudflare.com/cloudflare-outage/) — blog.cloudflare.com
- [Matthew Prince on X, Jul 2, 2019, 14:22 UTC](https://x.com/eastdakota/status/1146061591143538688) — x.com
- [Matthew Prince on X, Jul 2, 2019, 14:36 UTC ("No evidence yet attack related")](https://x.com/eastdakota/status/1146065231270907907) — x.com
- [Hacker News, Jul 2, 2019, 13:49 UTC — "Cloudflare Network Performance Issues" (631 points)](https://news.ycombinator.com/item?id=20334924) — news.ycombinator.com
- [Hacker News, Jul 2, 2019 — "Cloudflare outage caused by bad software deploy" (348 points)](https://news.ycombinator.com/item?id=20336332) — news.ycombinator.com
- [Hacker News, Jul 12, 2019 — "Details of the Cloudflare outage on July 2, 2019" (698 points)](https://news.ycombinator.com/item?id=20421538) — news.ycombinator.com
- [TechCrunch, Jul 2, 2019](https://techcrunch.com/2019/07/02/a-cloudflare-outage-is-impacting-sites-everywhere/) — techcrunch.com