Cloudflare, una de las piezas clave de la infraestructura de internet, ha reconocido que el apagón global sufrido el 18 de noviembre de 2025 fue consecuencia de un fallo interno en su propia red, y no de un ciberataque. Durante varias horas, millones de usuarios en todo el mundo vieron páginas de error en lugar de los sitios web que dependen de sus servicios de CDN y seguridad.
La compañía ha publicado un extenso informe técnico en el que detalla qué ocurrió, por qué sus mecanismos de protección fallaron y qué medidas piensa adoptar para evitar que algo similar vuelva a repetirse. El propio consejero delegado de Cloudflare admite que se trata de “el peor apagón desde 2019” y califica el incidente de “inaceptable” dada la importancia que la empresa tiene en el ecosistema de internet.
Un cambio aparentemente menor que tumbó la red global
El problema se originó el 18 de noviembre a las 11:20 (UTC), cuando la red de Cloudflare empezó a devolver masivamente errores HTTP 5xx, síntoma de un fallo interno en sus sistemas. Para los usuarios finales, esto se traducía en una página de error de Cloudflare en lugar del contenido habitual.
La causa no fue un ataque, sino una cadena de efectos desencadenada por un cambio en los permisos de uno de los sistemas de bases de datos que la empresa utiliza para alimentar su módulo de gestión de bots (Bot Management). Ese cambio hizo que una consulta en un clúster de bases de datos ClickHouse generase un fichero de configuración mucho más grande de lo esperado, con filas duplicadas.
Ese fichero, conocido como feature file, se distribuye cada pocos minutos a todos los servidores que forman la red de Cloudflare. Es el archivo que indica al sistema de detección de bots qué características debe tener en cuenta para puntuar cada petición y decidir si se trata de tráfico automatizado o legítimo.
Al duplicarse el número de características incluidas, el archivo superó un límite interno de tamaño previsto en el software que corre en los nodos de la red. El módulo de bots no estaba preparado para manejar más de 200 “features” y, al intentar procesar el fichero, provocó un fallo que hizo que el proxy central de Cloudflare dejase de funcionar correctamente y empezara a devolver errores 5xx a gran escala.
Un error intermitente que confundió al equipo y sugirió un ataque
Durante los primeros compases del incidente, los gráficos internos de la compañía mostraban un comportamiento extraño: el volumen de errores 5xx subía de forma brusca, luego se estabilizaba, después parecía mejorar y, al poco tiempo, volvía a dispararse. Este patrón intermitente hizo sospechar inicialmente de un posible ataque de denegación de servicio (DDoS) de gran escala.
La explicación llegó después: el fichero de características se generaba cada cinco minutos en el clúster de ClickHouse. Como la actualización de permisos no se había aplicado todavía a todos los nodos, en función de qué nodo ejecutase la consulta en cada momento, el archivo resultante podía ser “bueno” o “malo”. Eso provocaba que, durante un tiempo, la red funcionase con normalidad, hasta que se propagaba de nuevo un fichero defectuoso que volvía a desencadenar la cascada de errores.
A medida que la actualización de permisos se completó en todos los nodos, el comportamiento dejó de ser intermitente y el fallo se estabilizó en un estado de error permanente. A partir de ahí, el equipo de ingeniería logró aislar la causa: detener la generación del fichero incorrecto, sustituirlo por una versión anterior conocida como válida y forzar el reinicio de los servicios afectados.
Según la cronología interna, el tráfico esencial comenzó a recuperarse a partir de las 14:30 y la normalidad completa no llegó hasta las 17:06 (siempre en horario UTC), una vez reiniciados los servicios que habían quedado en estados incoherentes.
Cómo funciona el proxy de Cloudflare y por qué falló en cadena
Para entender el alcance del fallo, la compañía ha explicado el camino que sigue cada petición cuando un usuario accede a un sitio web que utiliza Cloudflare:
- La conexión se establece en la capa HTTP y TLS de la red.
- La petición entra en el proxy central (llamado internamente FL, Frontline), encargado de aplicar reglas de seguridad, de rendimiento y de enrutamiento.
- A través de un componente llamado Pingora, el sistema comprueba si el contenido está en caché o si debe ir al servidor de origen para recuperarlo.
En ese recorrido, la petición pasa por distintos módulos especializados: cortafuegos de aplicaciones web (WAF), protección DDoS, gestión de acceso, plataforma de desarrolladores, almacenamiento distribuido y, entre ellos, el módulo de Bot Management.
Este último usa un modelo de aprendizaje automático que asigna una puntuación de “probabilidad de ser bot” a cada petición. Para hacerlo, necesita cargar en memoria un fichero de configuración con las características (features) que alimentan al modelo.
Ese fichero se actualiza constantemente para adaptarse a nuevos patrones de tráfico y a tácticas cambiantes de los atacantes. Pero el diseño asumía que su tamaño sería relativamente estable y acotado. Cuando, debido al cambio en ClickHouse, el número de características superó el límite predefinido, el módulo de bots lanzó un error no gestionado que hizo fallar el proceso del proxy central. El resultado: la red dejó de poder enrutar tráfico con normalidad y empezó a responder con errores genéricos del tipo 5xx.
Diferencias entre la versión antigua y la nueva del proxy
En paralelo a todo esto, Cloudflare se encontraba en pleno proceso de migración hacia una nueva versión de su proxy, conocida internamente como FL2, escrita en Rust. Tanto la versión antigua (FL) como la nueva se vieron afectadas por el problema del fichero de características, pero de formas distintas.
- En FL2, el fallo en el módulo de bots se traducía directamente en errores HTTP 5xx visibles por los usuarios.
- En FL, el sistema no devolvía errores, pero todos los tráficos recibían una puntuación de bot igual a cero, lo que en la práctica podía provocar falsos positivos en las reglas de bloqueo basadas en esas puntuaciones.
Es decir, los clientes que ya estaban plenamente migrados a FL2 sufrieron un impacto más visible (páginas de error), mientras que en la versión antigua el efecto fue más sutil, ligado a la lógica de detección de bots, pero igualmente indeseado.
Servicios afectados: CDN, Workers KV, Access, Turnstile y panel de control
El fallo del proxy no solo afectó al servicio de CDN y seguridad principal, sino también a varios productos que dependen de esa misma ruta interna.
Entre los servicios impactados, la compañía destaca:
- Servicios principales de CDN y seguridad: devolvieron errores HTTP 5xx, la típica página de Cloudflare indicando un problema interno.
- Workers KV: el sistema de almacenamiento clave-valor para aplicaciones serverless devolvió niveles muy altos de errores, al depender de la pasarela frontal afectada.
- Cloudflare Access: los intentos de autenticación fallaron de forma masiva, aunque las sesiones ya activas siguieron funcionando.
- Turnstile: el sistema de protección en formularios se vio afectado, lo que impidió que muchos usuarios pudieran iniciar sesión en el panel de control de Cloudflare.
- Panel de administración (dashboard): aunque algunas funciones seguían operativas, el acceso de nuevos usuarios se vio obstaculizado por los problemas en Turnstile y en Workers KV.
- Email Security: no perdió capacidad de procesar correo, pero vio reducida temporalmente la precisión de sus sistemas de reputación IP y algunas acciones automáticas.
Además, durante el incidente se disparó la latencia de respuestas en la red de distribución de contenidos. No solo por el fallo en sí, sino porque los sistemas de observabilidad y depuración internos, al intentar capturar información de los errores, consumieron una gran cantidad de CPU adicional.
De sospechar un DDoS masivo a un bug en la configuración
Otro elemento que complicó el diagnóstico fue que, en paralelo, la página pública de estado de Cloudflare también dejó de funcionar, a pesar de estar alojada fuera de la propia infraestructura de la compañía. Este hecho, aunque terminó siendo una coincidencia, alimentó durante un tiempo la hipótesis de que se tratase de un ataque coordinado, tanto contra la red de Cloudflare como contra los sistemas externos donde informa de sus incidencias.
En los canales internos de comunicación, el equipo llegó a plantearse que pudiera tratarse de la continuación de una oleada reciente de ataques DDoS de gran volumen. No fue hasta que se correlacionaron los cambios en ClickHouse, el crecimiento anómalo del fichero de características y los límites de memoria del módulo de bots, cuando quedó claro que el origen era estrictamente interno.
Lecciones aprendidas y cambios prometidos
Con el servicio ya restablecido, Cloudflare ha enumerado varias líneas de trabajo para robustecer su plataforma frente a fallos similares:
- Endurecer la ingestión de ficheros de configuración generados internamente, tratándolos con las mismas cautelas que si fueran datos introducidos por usuarios externos.
- Introducir más “interruptores globales” (kill switches) que permitan desactivar rápidamente módulos concretos, como el de bots, sin tumbar el proxy completo.
- Evitar que volcados de memoria y sistemas de diagnóstico saturen los recursos en situaciones de error, para que las herramientas de observabilidad no agraven la crisis.
- Revisar los modos de fallo de todos los módulos del proxy central, con el fin de que un error en una pieza no pueda escalar hasta paralizar el tráfico de toda la red.
La compañía insiste en que un apagón de estas características “es inaceptable” y reconoce la gravedad de que, durante un periodo de tiempo, gran parte del tráfico core de internet que pasa por su red quedase interrumpido. Al mismo tiempo, subraya que cada incidente grave en su historia ha dado lugar a nuevas capas de resiliencia y rediseños internos.
En un ecosistema donde empresas, medios, administraciones públicas y servicios esenciales dependen de unos pocos grandes proveedores de infraestructura, el fallo del 18 de noviembre es un recordatorio de la fragilidad de la red y de la importancia de que estos actores transparenten lo que ocurre cuando algo se rompe. Cloudflare, al menos en esta ocasión, ha optado por mostrar su “caja negra” con todo detalle técnico y asumir la responsabilidad por uno de los mayores tropiezos de su historia reciente.
Fuentes:
- Informe técnico de Cloudflare “Cloudflare outage on November 18, 2025”, publicado en su blog corporativo.
vía: blog.cloudflare
