Aunque en un primer momento se especuló con un ataque masivo, la compañía ha confirmado que el incidente no tuvo origen malicioso, sino que respondió a un fallo interno en su sistema de gestión de bots. Se trata, según su CEO, Matthew Prince, de “la peor interrupción desde 2019”.
El servicio comenzó a degradarse a las 12:20 (hora peninsular española), cuando la red principal de Cloudflare empezó a fallar en la entrega de tráfico. Los usuarios que intentaban acceder a servicios protegidos por la infraestructura veían una página de error genérica que confirmaba la caída. Sin embargo, Cloudflare ha remarcado que el incidente “no fue causado, ni directa ni indirectamente, por un ciberataque ni por ninguna actividad maliciosa”.
En un primer momento, parte del equipo sospechó que podía tratarse de un ataque DDoS, especialmente cuando incluso la página de estado externa, que no depende de Cloudflare, dejó de funcionar. No obstante, la investigación interna confirmó un origen distinto: un error en un sistema crítico dedicado a gestionar el tráfico de bots.
El fallo se inició con un cambio aparentemente inocuo en los permisos de uno de los sistemas de bases de datos de Cloudflare. Esa modificación provocó que la base de datos generara entradas duplicadas en el archivo de “funcionalidades”, usado por el módulo de gestión de bots (Bot Management) para alimentar sus modelos de aprendizaje automático. El archivo duplicó su tamaño y se propagó automáticamente a todas las máquinas de la red.
Este archivo se actualiza cada pocos minutos para detectar nuevas amenazas. Pero al superar el límite de tamaño aceptado por el software que enruta el tráfico (el proxy FL/FL2), el sistema comenzó a fallar. Ese fallo desató una cascada de errores HTTP 5xx que afectó a los servicios CDN, Workers KV, Turnstile o Access, entre otros.
La complejidad del problema se agravó por un comportamiento intermitente: durante varias horas, algunos nodos generaban versiones correctas del archivo, mientras otros producían la versión defectuosa. Esto hizo que la red pareciera recuperarse para volver a caer minutos después, dificultando el diagnóstico inicial.
Cloudflare consiguió frenar la propagación del archivo defectuoso a las 15:24 (hora peninsular española) y restauró manualmente una versión válida. A las 15:30, el tráfico principal comenzó a recuperarse y, finalmente, a las 18:06 todos los servicios volvían a funcionar con normalidad.
Durante las horas posteriores, la compañía tuvo que gestionar sobrecargas adicionales en diferentes sistemas, provocadas por el regreso masivo del tráfico y por los múltiples intentos simultáneos de inicio de sesión en su panel de control.
La compañía ha anunciado una serie de medidas para evitar incidentes similares en el futuro, entre ellas: reforzar el sistema de ingesta de archivos de configuración; habilitar interruptores globales que permitan desactivar módulos críticos como Bot Management; revisar los modos de fallo de cada módulo del proxy; y evitar que procesos de depuración consuman recursos hasta paralizar los servicios principales.
Prince ha reconocido que una interrupción como esta es “inaceptable” y ha pedido disculpas a los clientes, remarcando el impacto que un incidente de este tipo tiene para un proveedor que gestiona una parte sustancial del tráfico mundial.