El gigante de infraestructura web experimentó más de 5 horas de interrupciones el 18 de noviembre de 2025 debido a un error en la configuración de su sistema de gestión de bots
El día de ayer quedará marcado como uno de los días más oscuros en la historia de Cloudflare. A las 11:20 UTC, la red de esta compañía —que protege millones de sitios web en todo el mundo— comenzó a experimentar fallos masivos que impidieron el acceso a una cantidad incontable de servicios en internet. La caída duró más de cinco horas, afectando no solo a sus servicios principales de CDN y seguridad, sino también a herramientas críticas como Workers KV, Access y hasta su propio panel de control.
¿Qué provocó el colapso de Cloudflare?
Contrariamente a lo que muchos podrían pensar ante un incidente de esta magnitud, no se trató de un ciberataque masivo ni de actividad maliciosa. El origen del problema fue mucho más mundano, aunque igualmente devastador: un cambio en los permisos de uno de sus sistemas de bases de datos ClickHouse.
Este ajuste, implementado a las 11:05 UTC con el objetivo de mejorar la gestión de permisos y la seguridad de las consultas distribuidas, tuvo una consecuencia imprevista. Provocó que una consulta SQL utilizada para generar el «archivo de características» del sistema de Bot Management devolviera filas duplicadas, duplicando efectivamente el tamaño del archivo.
El efecto dominó: cuando un archivo crece demasiado
El archivo de características en cuestión es fundamental para el funcionamiento del sistema de Bot Management de Cloudflare. Este sistema utiliza modelos de aprendizaje automático para asignar puntuaciones a cada solicitud que atraviesa la red, determinando si proviene de un bot o de un usuario legítimo. El archivo se actualiza cada pocos minutos para adaptarse a las amenazas cambiantes en internet.
El problema surgió cuando el software del proxy principal de Cloudflare, que procesa todo el tráfico de clientes, tenía un límite preestablecido de 200 características. El sistema normalmente utilizaba alrededor de 60, dejando un margen considerable. Sin embargo, con las filas duplicadas, el archivo superó este límite, provocando que el código Rust del nuevo sistema FL2 entrara en pánico y devolviera errores HTTP 5xx a los usuarios.
Los servicios afectados y su impacto
La caída no fue uniforme. Los clientes que utilizaban el nuevo motor de proxy FL2 experimentaron errores HTTP 5xx directos. Aquellos aún en el sistema antiguo FL no vieron errores de acceso, pero su sistema de puntuación de bots dejó de funcionar correctamente, asignando una puntuación de cero a todo el tráfico. Esto generó numerosos falsos positivos para quienes tenían reglas configuradas para bloquear bots.
Otros servicios críticos también quedaron fuera de servicio:
- Turnstile: El sistema de verificación humana dejó de cargar, impidiendo que los usuarios iniciaran sesión en múltiples plataformas.
- Workers KV: Experimentó errores masivos debido a la dependencia del proxy principal.
- Cloudflare Access: Las autenticaciones fallaron de manera generalizada hasta las 13:05 UTC.
- Panel de control: La mayoría de usuarios no pudieron acceder debido a que Turnstile protegía la página de inicio de sesión.
La confusión inicial: ¿un ataque coordinado?
Lo que hizo especialmente complejo el diagnóstico inicial fue el comportamiento errático del sistema. Como el archivo problemático se generaba cada cinco minutos y dependía de qué nodo de ClickHouse procesara la consulta, el sistema alternaba entre estados funcionales y fallidos. Esta fluctuación llevó al equipo de Cloudflare a sospechar inicialmente de un ataque DDoS masivo, especialmente del tipo Aisuru que había afectado recientemente a diversos servicios.
Para agregar más confusión, la página de estado de Cloudflare —alojada completamente fuera de su infraestructura— también cayó por coincidencia, reforzando la teoría del ataque coordinado. Sin embargo, esto resultó ser una casualidad sin relación con el incidente principal.
La recuperación: un proceso gradual
El equipo de Cloudflare identificó correctamente el problema a las 14:24 UTC, cuando detuvieron la generación automática de nuevos archivos de configuración para Bot Management. A las 14:30 UTC desplegaron manualmente un archivo correcto conocido y forzaron el reinicio del proxy principal, lo que restauró el flujo de tráfico principal.
Sin embargo, la recuperación completa llevó más tiempo. Los intentos de inicio de sesión acumulados durante la caída, combinados con reintentos automáticos, sobrecargaron el panel de control hasta las 15:30 UTC. No fue hasta las 17:06 UTC que todos los sistemas volvieron a la normalidad.
Lecciones aprendidas y medidas futuras
Matthew Prince, CEO de Cloudflare, calificó este incidente como «la peor caída desde 2019» y ofreció disculpas públicas. La compañía ya está implementando medidas correctivas:
- Refuerzo de la validación de archivos de configuración: Tratar los archivos generados internamente con el mismo rigor que la entrada de usuarios.
- Interruptores de emergencia globales: Habilitar más mecanismos para desactivar rápidamente características problemáticas.
- Gestión de recursos en errores: Evitar que los volcados de memoria y reportes de errores consuman recursos del sistema durante incidentes.
- Revisión de modos de fallo: Análisis exhaustivo de cómo responden todos los módulos del proxy ante condiciones de error.
¿Qué significa esto para la arquitectura de internet?
Este incidente pone de relieve la fragilidad inherente de la infraestructura centralizada de internet. Cloudflare, que protege aproximadamente el 20% del tráfico web mundial, se ha convertido en un punto único de fallo. Cuando su red cae, millones de sitios web y servicios quedan inaccesibles simultáneamente.
El hecho de que un cambio aparentemente menor en una base de datos —diseñado precisamente para mejorar la seguridad— pueda desencadenar un colapso de esta magnitud demuestra la complejidad extrema de los sistemas modernos de infraestructura web. También subraya la importancia de pruebas exhaustivas, límites de seguridad bien dimensionados y sistemas de monitoreo que puedan detectar anomalías antes de que se propaguen globalmente.
Para desarrolladores y administradores de sistemas, este caso ofrece varias lecciones valiosas: la importancia de establecer límites realistas con margen de crecimiento, la necesidad de validar incluso los archivos de configuración generados internamente, y la criticidad de tener mecanismos de rollback rápidos para cualquier cambio que se despliegue en producción.
La transparencia de Cloudflare al publicar un análisis técnico detallado del incidente es encomiable y representa una práctica que toda la industria debería emular. Sin embargo, para millones de usuarios y empresas que dependían de sus servicios durante esas cinco horas, el recordatorio fue claro: incluso los gigantes pueden caer.
