El 18 de noviembre de 2025, la infraestructura de Cloudflare, uno de los principales proveedores mundiales de CDN y seguridad perimetral, sufrió uno de sus incidentes más graves de los últimos años. Un fallo interno en la generación de un archivo de configuración crítico provocó interrupciones masivas en sitios web y servicios online a escala global. La propia compañía aclaró posteriormente que no se trató de un ciberataque, sino de un error de configuración al modificar permisos de acceso en su base de datos analítica.
Incidente de Cloudflare 2025: qué ocurrió realmente
Los primeros síntomas aparecieron alrededor de las 11:20 UTC, cuando múltiples servicios que usan Cloudflare como proxy inverso y escudo de seguridad empezaron a mostrar problemas intermitentes de disponibilidad. El patrón de “cae, se recupera y vuelve a caer” llevó inicialmente a sospechar de una posible ataque DDoS a gran escala, dado que este comportamiento recuerda a los ciclos de mitigación automática de ataques.
Sin embargo, el análisis forense interno reveló que el origen era puramente interno. Durante una actualización de permisos en un clúster de ClickHouse —la base de datos analítica distribuida que Cloudflare utiliza para procesar grandes volúmenes de telemetría— se ejecutó una consulta errónea. Esta consulta generó un archivo de características defectuoso para el sistema de Bot Management, desencadenando la cadena de fallos.
ClickHouse, Bot Management y el archivo de características
Cloudflare se apoya intensamente en la analítica de tráfico para distinguir entre usuarios legítimos y actividad automatizada maliciosa. Un clúster específico de ClickHouse construye de forma continua un feature file: un archivo que describe características de comportamiento de bots (patrones de solicitudes, firmas, metadatos, etc.).
Este archivo se distribuye a los proxies de Cloudflare de todo el mundo y se utiliza como pieza clave de configuración para tomar decisiones en tiempo real sobre bloqueo, desafío o enrutamiento de peticiones sospechosas. Se convierte, en la práctica, en un punto único de dependencia: cualquier corrupción en su estructura o tamaño puede afectar simultáneamente a una parte sustancial de la red.
De un simple cambio de permisos a una cadena de fallos
El cambio planificado en ClickHouse pretendía habilitar acceso a datos y metadatos de menor nivel para análisis avanzados. No obstante, la consulta asociada al ajuste de permisos estaba mal diseñada y devolvió más información de la prevista. Como resultado, el feature file generado por el clúster duplicó aproximadamente su tamaño habitual.
Los proxies de Cloudflare tenían configurado un límite estricto de tamaño para dicho archivo. Al superar el umbral, los procesos de proxy consideraban el archivo inválido y terminaban de forma abrupta. Para agravar el problema, el clúster generaba una nueva versión del archivo cada cinco minutos, reinyectando el error de forma periódica y creando un patrón ondulante de caídas y recuperaciones parciales.
Efecto “flapping” y falsa apariencia de ataque DDoS
El comportamiento fue aún más complejo debido a que no todos los nodos de ClickHouse recibieron los nuevos permisos al mismo tiempo. Solo una parte de los nodos generaba archivos sobredimensionados, mientras otros seguían produciendo versiones correctas. Esto provocó un efecto de “flapping”: algunos proxies cargaban una configuración válida y funcionaban con normalidad, mientras otros recibían el archivo defectuoso y se caían.
Este vaivén generó la impresión externa de una ofensiva coordinada, ya que la red parecía recuperarse para volver a fallar de inmediato. Hacia las 13:00 UTC, todos los nodos del clúster pasaron a generar la versión corrupta del archivo, llevando a la infraestructura a un estado de fallo estable, con interrupciones generalizadas y persistentes.
Impacto global en CDN y servicios críticos en Internet
Los problemas afectaron a numerosos centros de datos de Cloudflare en Europa, incluidos Ámsterdam, Berlín, Fráncfort, Varsovia, Viena, Zúrich y Estocolmo, entre otras localizaciones. Plataformas de monitorización públicas registraron decenas de miles de avisos de indisponibilidad de sitios, proveedores de hosting y aplicaciones SaaS.
Usuarios de todo el mundo reportaron dificultades de acceso a grandes servicios en línea que dependen de Cloudflare para su CDN y protección frente a ataques, entre ellos Spotify, Twitter, OpenAI, Anthropic, AWS, Google y muchos otros. El incidente volvió a poner de manifiesto un aspecto crítico de la ciberseguridad moderna: la fuerte dependencia del ecosistema digital de un pequeño grupo de proveedores de infraestructura.
Cómo se contuvo la caída y medidas anunciadas por Cloudflare
Para frenar la crisis, el equipo de ingeniería detuvo la generación de archivos defectuosos, inyectó manualmente en la cola de distribución una versión conocida y válida de la configuración y ejecutó un reinicio forzado de los proxies principales. La restauración completa de los servicios se prolongó alrededor de seis horas, hasta aproximadamente las 17:44 UTC, cuando la red volvió a su comportamiento normal.
Cloudflare calificó el suceso como su incidente más grave desde 2019, año en el que otra regla de configuración mal aplicada provocó una caída relevante de su red. Entre las medidas anunciadas se incluyen el refuerzo de la validación automática de archivos de configuración, la introducción de kill switches adicionales para desactivar rápidamente componentes problemáticos y la revisión profunda de la lógica de manejo de errores en los módulos de proxy críticos.
Lecciones clave de ciberseguridad y resiliencia para las organizaciones
Este episodio confirma varias buenas prácticas para equipos de ciberseguridad y operaciones:
1. Validación y pruebas de configuración: las configuraciones generadas dinámicamente deben someterse a validaciones sintácticas, semánticas y de tamaño antes de su propagación. Incidentes previos de grandes proveedores, como Cloudflare (2019) o el fallo de Fastly en 2021, han demostrado el impacto potencial de un único cambio mal probado.
2. Despliegues canarios y controles de cambio: la introducción de nuevas reglas o permisos en sistemas críticos debería comenzar en un subconjunto de la infraestructura (canary release) con capacidad de rollback inmediato si se detectan anomalías.
3. Límites y aislamiento de puntos únicos de fallo: un archivo de configuración centralizado para la seguridad de bots es muy potente, pero también concentra riesgo. Es recomendable diseñar mecanismos de degradación controlada (por ejemplo, volver a un perfil de seguridad por defecto) cuando ese artefacto no sea válido o no esté disponible.
4. Observabilidad avanzada: contar con métricas, trazas y registros que permitan distinguir rápidamente entre un incidente interno y un ataque externo reduce el tiempo de diagnóstico y evita decisiones reactivas basadas en suposiciones erróneas.
Las organizaciones que dependen de proveedores de nube, CDN y servicios gestionados deberían aprovechar este caso para revisar sus propios procesos: gestión de permisos en bases de datos críticas, límites en artefactos de configuración, capacidad de revertir cambios de forma global y planes de continuidad de negocio multi-proveedor. Invertir en estos mecanismos reduce el riesgo de que un único error de configuración se convierta en un fallo global y refuerza la resiliencia de todo el ecosistema digital.
