Non foi un ataque nin un hacker xenial. Foi un ficheiro de configuración que creceu máis do que debía, e iso chegou para tombar medio internet durante horas.
Cando unha web cae, o primeiro pensamento é que alguén a atacou. Pois o 18 de novembro de 2025 non. Cloudflare caeu e levou consigo unha boa parte de internet por culpa dun cambio interno e dun ficheiro que engordou máis do permitido.
Segundo a análise de ilert, a cadea empezou ás 11:05 UTC cando se desplegou un cambio de permisos nunha base de datos ClickHouse. Ás 11:20 UTC comezaron os erros.
Como un ficheiro tomba a rede
O cambio fixo que unha consulta devolvese filas duplicadas. Esas filas serviron para xerar o ficheiro de características que usa o sistema de Bot Management, que acabou cun tamaño máis do dobre do normal. Pinggy precisa que había un límite fixo de 200 características no código do proxy e que o habitual rondaba as 60. Ao pasar o límite, o software non soubo xestionalo e devolveu erros 5xx.
Tampouco foi un fallo constante. O ficheiro regenerábase cada cinco minutos e só saía mal cando a consulta pasaba por nodos xa actualizados, polo que o servizo ía e viña antes de quedar atascado.
Cronoloxía e danos
Ás 13:05 UTC engadíronse desvíos para Workers KV e Access. A xeración automática de ficheiros novos detívose ás 14:24 UTC e, ás 14:30, Cloudflare repuxo en todo o mundo unha configuración anterior que funcionaba. O tráfico principal volveu a normalizarse entón; a recuperación completa chegou ás 17:06 UTC.
Non só falou a CDN: ilert tamén cita Turnstile, que impediu moitos accesos ao panel, Workers KV, Access e o servizo Email Security. Pinggy, que advirte de que non verificou os datos de forma independente, enumera servizos de terceiros afectados, como ChatGPT, X, Spotify, Canva, Discord, Figma ou Vercel.
A nosa lectura
Hai unha lección incómoda para quen aloxa clientes: calquera dependencia única, por boa que sexa, é un punto de fallo. Cloudflare é un servizo magnífico, e precisamente por iso tanta xente depende del sen darse conta. Cando cae, cae todo xunto.
Para unha axencia, o plan non é abandonar a CDN, senón saber que pasa se falla. Ter un protocolo de comunicación co cliente, unha páxina de estado alternativa e claro quen toma que decisión nunha tarde así. O mellor plan de continxencia é o que ensaiaches antes de precisalo.
