Caso Cloudflare 2025 — Autopsia de una caída global de internet

1 Resumen ejecutivo

2 Contexto: por qué cuando cae Cloudflare parece que “se rompe internet”

Cloudflare no es sólo un CDN: es una plataforma global que combina distribución de contenido, protección anti-DDoS, firewall de aplicaciones, DNS gestionado y reverse proxy. Aproximadamente una quinta parte del tráfico web mundial pasa, directa o indirectamente, por su red.

Eso significa que cuando Cloudflare se cae, no se cae “un sitio”, sino una capa entera del ecosistema: IA generativa (ChatGPT, otros LLM expuestos vía web), herramientas de productividad, tiendas online, gateways de pago y servicios públicos.

Una forma intuitiva de verlo: Cloudflare es el vigilante de la discoteca. La discoteca (el servidor de la empresa) puede estar bien, con espacio disponible, pero si el vigilante se vuelve loco y no deja entrar a nadie, para el usuario el sitio “está caído”.

3 Cronología del incidente

La cronología combinada de postmortem + observación de clientes se puede resumir así (horas aproximadas):

• 11:20 UTC (~6:20 a.m. Miami) – La red de Cloudflare comienza a presentar fallas importantes en la distribución del tráfico. Se dispara el volumen de errores HTTP 5xx.
• Minutos siguientes – Monitores de terceros y redes sociales detectan que servicios como X/Twitter, ChatGPT, plataformas de IA y varios sitios críticos empiezan a devolver errores.
• 11:20–14:30 UTC – Ventana de impacto fuerte. Cloudflare intenta mitigar el problema; los gráficos muestran picos de errores, caídas parciales y reapariciones del fallo.
• 14:30 UTC (~9:30 a.m.) – Se identifica correctamente el problema del archivo de características (feature file) sobredimensionado y se detiene su propagación, reemplazándolo por una versión anterior.
• 14:30–17:06 UTC – La red se va estabilizando. Se reduce la sobrecarga en distintas zonas mientras el tráfico normal regresa.
• 17:06 UTC (~12:06 p.m.) – Cloudflare declara que todos sus sistemas funcionan con normalidad, aunque muchos usuarios siguen notando “resaca” (fallos intermitentes, caches no actualizados) durante varias horas más.

4 Causa raíz técnica: el archivo de features de bots

4.1. Qué es el “feature file” de gestión de bots

Cloudflare mantiene un sistema de gestión de bots (Bot Management) que:

• Detecta patrones de tráfico sospechosos (bots maliciosos, scrapers, intentos de DDoS).
• Distingue entre humanos reales, bots “buenos” (indexadores, crawlers) y bots maliciosos.
• Se basa en un conjunto de “características” (features) que se actualizan constantemente.

Esas características se empaquetan en un archivo de features que se distribuye a los nodos de la red de Cloudflare y se regenera cada pocos minutos para reflejar nuevas amenazas detectadas.

4.2. El cambio de permisos que lo desencadena todo

En un clúster de base de datos se realiza un cambio de permisos con la intención de mejorar la gestión interna. Como efecto colateral no previsto:

• La consulta que genera el archivo de características empieza a devolver registros de forma diferente.
• Ese cambio provoca que el archivo crezca mucho más de lo previsto (duplicación de información, aumento de filas, etc.).
• El nuevo archivo resultante supera los límites de tamaño/memoria que el software de proxy estaba preparado para manejar.

4.3. Efecto en los nodos de la red

Cada nodo de la red de Cloudflare que recibe el archivo sobredimensionado intenta cargarlo en el proceso que maneja Bot Management y el proxy. Al sobrepasar los límites:

• El módulo encargado de manejar bots entra en fallo.
• En muchos casos, el fallo impacta al proxy que enruta el tráfico web, devolviendo errores 5xx a los usuarios finales.
• Como el archivo se regenera cada pocos minutos, el problema reaparece una y otra vez, incluso después de mitigaciones temporales.

5 ¿Fue un ataque? Diferencia entre DDoS y bug interno

Los primeros síntomas (errores 5xx masivos, comportamiento errático) son típicos de un ataque de denegación de servicio distribuido (DDoS), donde un atacante envía grandes cantidades de tráfico para saturar un servicio.

Sin embargo:

• No hubo ataque DDoS que derribara a Cloudflare.
• No se detectó actividad maliciosa que explicara el patrón de fallas.
• El origen fue un cambio de permisos que disparó un bug latente en el pipeline que genera el archivo de características de bots.

Es decir, el incidente no fue consecuencia de que “la seguridad de Cloudflare fallara frente a un atacante externo”, sino de un fallo de ingeniería interna y de gobierno de cambios.

6 Impacto visible y efectos colaterales

6.1. Servicios afectados

Entre los servicios que se reportaron con problemas durante la caída se incluyen:

• Plataformas de IA y chat (incluyendo ChatGPT y otros modelos expuestos vía web).
• Redes sociales (como X/Twitter, entre otras que usan Cloudflare para WAF/DNS/CDN).
• Tiendas online, soluciones de comercio electrónico y pasarelas de pago.
• Servicios públicos y de transporte (páginas de transporte regional, reguladores y organismos oficiales en varios países).

6.2. Duración y “resaca” técnica

Aunque el tráfico principal se declaró “en gran medida normal” alrededor de las 14:30 UTC, y los sistemas “completamente normalizados” a las 17:06 UTC, muchos usuarios siguieron notando:

• Errores esporádicos al acceder a sitios que dependen de Cloudflare.
• Inconsistencias por caches, proxies intermedios y rutas que tardan más en actualizarse.
• Reportes de caída de servicios “horas después” de la supuesta resolución oficial.

7 Lecciones de arquitectura y operación

• Gestión de cambios crítica: cambios en permisos, esquemas y consultas de datos deben pasar por pipelines de validación tan rigurosos como el código de producción.
• Límites explícitos y observables: archivos de configuración, modelos y artefactos deberían tener validaciones de tamaño estrictas, con alertas tempranas y rechazo automático si se salen de rango.
• Fail-open vs fail-closed: en módulos como gestión de bots, puede ser preferible degradar la seguridad (fail-open parcial) antes que provocar una caída total del servicio (fail-closed duro).
• Reducción del blast radius: aislar mejor los componentes (por ejemplo, que un fallo en Bot Management no pueda tumbar el proxy principal que sirve el tráfico HTTP).
• Observabilidad profunda: dashboards que crucen errores 5xx, despliegues de configuración, tamaño de archivos críticos y cambios de permisos ayudan a detectar este tipo de bucles (“arreglo → se vuelve a romper”) mucho más rápido.

1 Executive summary

2 Context: why a Cloudflare outage feels like “the internet is broken”

Cloudflare is not just a CDN. It is a global platform that combines content delivery, anti-DDoS protection, web application firewall, managed DNS and reverse proxy. Roughly one fifth of global web traffic passes directly or indirectly through its infrastructure.

This means that when Cloudflare goes down, it is not “one website” that fails, but a whole layer of the ecosystem: generative AI frontends (ChatGPT, other LLM interfaces), productivity tools, online stores, payment gateways and public services.

A simple analogy: Cloudflare is the nightclub bouncer. The club (the origin server) might be healthy and have capacity, but if the bouncer goes crazy and does not let anyone in, the user perceives the site as “down”.

3 Incident timeline

Combining the official postmortem and customer observations, the timeline can be summarized as follows (approximate times):

• 11:20 UTC – Cloudflare’s network begins to experience significant failures in traffic distribution. HTTP 5xx error rates spike sharply.
• Minutes later – Third-party monitors and social media indicate that X/Twitter, ChatGPT, AI platforms and multiple critical sites are returning errors.
• 11:20–14:30 UTC – Main impact window. Cloudflare attempts mitigation, while dashboards show waves of errors, partial recoveries and relapses.
• 14:30 UTC – The oversized bot feature file is correctly identified as the root cause. Its propagation is stopped and an older valid version is pushed.
• 14:30–17:06 UTC – The network gradually stabilizes. Load is reduced on hot areas while normal traffic ramps back.
• 17:06 UTC – Cloudflare declares all systems fully operational, although many users still report intermittent problems and caching issues for several hours.

4 Technical root cause: the bot feature file

4.1. What the bot “feature file” is

Cloudflare maintains a Bot Management system that:

• Detects suspicious traffic patterns (malicious bots, scrapers, DDoS attempts).
• Distinguishes humans from “good” bots (indexers, crawlers) and harmful ones.
• Relies on a set of features that is updated continuously.

These features are bundled into a file that is distributed to Cloudflare’s edge nodes and regenerated every few minutes to reflect new threats and classifications.

4.2. The permissions change that triggered everything

A permissions change is applied to a database cluster, aiming to improve internal management. As an unintended side effect:

• The query generating the feature file starts returning data differently.
• The file grows much larger than expected (duplicate data, extra rows, etc.).
• The resulting artifact exceeds the size/memory limits that the proxy software was designed to handle.

4.3. Effect on network nodes

Each Cloudflare node receiving the oversized file tries to load it into the Bot Management and proxy processes. Once limits are exceeded:

• The module responsible for bot handling fails.
• In many cases, this failure affects the main proxy process that routes HTTP traffic, causing 5xx errors to end users.
• Because the file is regenerated every few minutes, the issue keeps reappearing, even after temporary mitigations.

5 Was it an attack? DDoS vs internal bug

The first symptoms (mass 5xx errors, erratic behavior) are classic for large DDoS attacks, where attackers flood a service with traffic to overwhelm it.

However, the postmortem and subsequent analysis show clearly:

• No DDoS attack actually brought Cloudflare down.
• No malicious activity matches the observed patterns.
• The root cause was a permissions change that triggered a latent bug in the bot feature file generation pipeline.

In short, the outage was not the result of Cloudflare’s defenses being defeated by an external adversary, but of an internal engineering and change-management failure.

6 Visible impact and side effects

6.1. Affected services

Among the services reported as impacted during the outage:

• AI and chat platforms (including ChatGPT and other web-exposed LLMs).
• Social networks (such as X/Twitter, and others using Cloudflare for WAF/DNS/CDN).
• Online shops, e-commerce stacks and payment gateways.
• Public and transportation services (regional transit sites, regulators and official portals in multiple countries).

6.2. Duration and technical “aftershock”

Even though Cloudflare declared core traffic “mostly normal” around 14:30 UTC and “fully restored” at 17:06 UTC, many users continued to experience:

• Sporadic errors when accessing Cloudflare-backed sites.
• Inconsistencies due to caches, intermediate proxies and routes lagging behind.
• Reports of failures “hours after” the official resolution time.

7 Architecture and operations lessons

• Critical change management: changes to permissions, schemas and data queries must go through validation pipelines as strict as production code deployments.
• Explicit, observable limits: config files, models and critical artifacts should have strong size validations, early alerts and automatic rejection when out of range.
• Fail-open vs fail-closed: for components like bot management, it may be preferable to degrade security (partial fail-open) instead of triggering a full availability outage (hard fail-closed).
• Blast radius reduction: components should be isolated so that failures in Bot Management cannot easily take down the main HTTP proxy layer.
• Deep observability: dashboards that cross 5xx error spikes with config deployments, file sizes and permissions changes can reveal “fix → break again” loops much faster.