Primero sonó a DDoS. Luego, a medida que se abrían los logs y se cruzaban señales, el diagnóstico cambió: nada de atacantes a las puertas. La propia Cloudflare reconoce que la interrupción masiva del 18 de noviembre nació dentro de casa, a raíz de un cambio de permisos que desató una cadena de errores en su módulo de bots. El CEO, Matthew Prince, firmó la autopsia técnica y prometió correcciones de proceso. El Internet perimetral más grande del mundo, parado por un fichero mal generado.
¿Que es lo que sucedió realmente?
La pieza en el centro del problema fue la “feature file” que alimenta el modelo de Bot Management, el sistema que puntúa bots en cada solicitud para que los clientes decidan si bloquean o permiten el tráfico. Ese archivo se actualiza cada pocos minutos; un cambio en el mecanismo que lo genera alteró su tamaño y disparó fallos en cascada. Resultado: el proxy que procesa el tráfico devolvió HTTP 5xx para cualquier petición que dependía del módulo de bots. No hubo intrusión ni explotación: fue una regresión de permisos en bases de datos que terminó rompiendo la predicción del modelo.
Más contexto: Bot Management se ha vuelto estratégico en plena guerra contra los “scrapers” de IA. Cloudflare incluso experimenta con “pay per crawl”, permitiendo el acceso a ciertos bots a cambio de pago. Que esa capa se detuviera explica por qué tantas webs notaron el golpe a la vez: es una compuerta común por la que pasa gran parte de la Red.
Cloudflare califica el episodio como su peor caída en años —no sufría una interrupción que parase la mayor parte del tráfico desde 2019, y la cronología encaja con el pánico inicial: primero se sospechó de un DDoS, luego se confirmó el fallo interno y, por último, se mitigó restableciendo la generación del archivo y corrigiendo permisos.
Impacto y lecciones para la industria
Para usuarios y servicios, el síntoma fue claro: páginas que no cargaban y apps devolviendo 5xx. Para los equipos de ingeniería, la lectura es otra: cuando la capa de control de bots vive tan cerca del plano de datos, un simple desajuste de configuración puede provocar un “brownout” global.
Por si fuera poco, la dependencia de modelos y archivos de features convierte la observabilidad en un requisito vital. Canary releases, validaciones de tamaño/forma del archivo, rollbacks automáticos y límites de blast radius no son lujos, son salvavidas. En cambio, la narrativa de “todo fue un ataque” ya no sirve: la resiliencia moderna también va de gobernanza de features y permisos no solo de firewalls o WAF.
Lo mejor es que este post mortem público debería presionar a toda la cadena (CDN, edge, APIs) para separar críticos de control y rutas de datos, endurecer feature flags y simular fallos en producción. Si la IA pide más puertas, la arquitectura tiene que poner más fusibles.
Puedes seguir a HardwarePremium en Facebook, Twitter (X), Instagram, Threads, BlueSky o Youtube. También puedes consultar nuestro canal de Telegram para estar al día con las últimas noticias de tecnología.
FAQ — Caída de Cloudflare: dudas rápidas
No. Cloudflare descarta actividad maliciosa; el origen fue un cambio de permisos que afectó a un archivo del módulo de bots.
Es la configuración que el modelo usa para puntuar si una solicitud es automática o legítima. Un cambio alteró su tamaño y provocó fallos.
Porque muchas dependen del enrutado/proxy de Cloudflare; al fallar el módulo de bots, el proxy devolvió 5xx en cascada.
No hay indicios de acceso no autorizado; fue un problema de configuración interna, no de seguridad.
El CEO pidió disculpas y detalló la causa; el aprendizaje pasa por controles más estrictos en permisos, validaciones del archivo y despliegues más seguros.
