Interrupción de Cloudflare el 5 de diciembre de 2025

 (blog.cloudflare.com)
1 puntos por GN⁺ 2025-12-06 | 1 comentarios | Compartir por WhatsApp
  • A las 08:47 UTC del 5 de diciembre de 2025, una parte de la red de Cloudflare sufrió una interrupción grave y se recuperó por completo a las 09:12, unos 25 minutos después
  • Aproximadamente el 28 % del tráfico HTTP total se vio afectado y solo clientes bajo ciertas condiciones experimentaron la interrupción
  • La causa fue un cambio en el WAF (lógica de análisis del cuerpo) para abordar una vulnerabilidad de React Server Components (CVE-2025-55182), sin relación con un ataque cibernético
  • Ocurrió un error de código en el proxy FL1 que generó errores HTTP 500; en el nuevo proxy FL2 basado en Rust no se reprodujo el mismo problema
  • Cloudflare reconoció que el problema se repitió tras el incidente del 18 de noviembre y está llevando como prioridad máxima un proyecto para reforzar la seguridad y resiliencia del despliegue

Resumen del incidente

  • El 5 de diciembre de 2025 a las 08:47 UTC, una parte de la red de Cloudflare experimentó una caída
    • Se recuperó toda la prestación del servicio a las 09:12, con un impacto total de 25 minutos
    • Aproximadamente el 28 % del tráfico HTTP total se vio afectado
  • La interrupción no estaba relacionada con un ataque cibernético ni actos maliciosos, ocurrió durante un cambio interno de configuración
  • La causa fue una modificación en la lógica de análisis del cuerpo en WAF para atender la nueva vulnerabilidad de React Server Components

Causa y contexto técnico

  • Cloudflare WAF almacena en memoria el cuerpo de la solicitud HTTP para detectar cargas útiles maliciosas
    • Se estaba ampliando el tamaño del búfer de 128 KB a 1 MB
  • Como la herramienta interna de pruebas no admitía el nuevo tamaño de búfer, se realizó una segunda modificación para desactivar esa herramienta
    • Este cambio se propagó de inmediato a todos los servidores a través del sistema de configuración global
  • Esta modificación provocó un estado de error en el proxy FL1 y errores de respuesta HTTP 500
    • Mensaje de error: attempt to index field 'execute' (a nil value)
  • El problema se identificó de inmediato y el cambio se revirtió a las 09:12

Alcance del impacto

  • Solo se vieron afectados los clientes que usan el proxy FL1 y tienen aplicado Cloudflare Managed Ruleset
    • Todos los requests de esos sitios devolvían errores HTTP 500
    • Algunos endpoints de prueba como /cdn-cgi/trace fueron excepciones
  • La red de China y clientes con otras configuraciones no se vieron afectados

Detalle del error en tiempo de ejecución

  • El sistema de rulesets de Cloudflare evalúa reglas por cada solicitud
    • Las reglas están compuestas por filtros y acciones, y la acción execute invoca otro conjunto de reglas
  • El sistema interno de registro usa execute para evaluar reglas de prueba
  • El sistema de killswitch está diseñado para desactivar reglas defectuosas, sin embargo
    • Esta fue la primera vez que se aplicó un killswitch a una regla que incluía la acción execute
  • Al intentar acceder a un objeto execute inexistente, se produjo un error de Lua
  • Este fue un error de código simple que existía desde hacía años sin ser detectado
    • En el proxy FL2 escrito en Rust no se presentó ese error

Avances desde el incidente del 18 de noviembre

  • También ocurrió un incidente de gran alcance por despliegue global el 18 de noviembre
  • En ese momento, se comunicó directamente con cientos de clientes y se compartió un plan para evitar la propagación masiva de una sola actualización
  • Al no haberse completado esa mejora todavía, esto influyó en el incidente actual
  • Cloudflare lo estableció como prioridad máxima para toda la organización

Proyectos de resiliencia en curso

  • Enhanced Rollouts & Versioning
    • Aplicar despliegue gradual, validación de salud y capacidad de rollback rápido también a cambios de datos de respuesta a amenazas y de configuración
  • Streamlined Break Glass Capabilities
    • Asegurar la posibilidad de intervención de emergencia también en interacciones entre servicios internos y plano de control
  • Manejo de errores Fail-Open
    • Ante un error en el archivo de configuración, no bloquear solicitudes y pasar al estado normal por defecto o permitir que el tráfico siga
    • Se habilitará una opción para elegir entre fail-open/fail-closed en algunos servicios
  • Los detalles completos de todos los proyectos de resiliencia se compartirán la próxima semana
  • Hasta entonces se mantiene un lockdown con cambios de red en pausa total

Cronograma (UTC)

  • 08:47 – Inicio del despliegue de cambio de configuración y propagación en red
  • 08:48 – Inicio del impacto total
  • 08:50 – Declaración del incidente por alerta automática
  • 09:11 – Inicio de reversión del cambio
  • 09:12 – Finalización de la recuperación, normalización de todo el tráfico

Conclusión

  • Cloudflare reconoció la gravedad de dos incidentes consecutivos y pidió disculpas a sus clientes y al internet en general
  • Busca prevenir eventos similares mejorando seguridad del despliegue, tolerancia a fallos y resiliencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-06
Opiniones de Hacker News

  • Esta caída de Cloudflare no fue solo un bug simple de Lua, sino un incidente que dejó al descubierto un problema arquitectónico de fondo.
    La estructura web distribuida original era mucho más resistente a este tipo de fallas globales. En cambio, los sistemas centralizados y homogéneos como Cloudflare pueden detener servicios de todo el mundo al mismo tiempo por un solo error. Aunque esté escrito en Rust, la gente igual se equivoca. Al final, lo importante es un diseño robusto

    • En otras palabras, mientras más dependamos de gigantes como Cloudflare o AWS, más baja la estabilidad de la web
    • Como en la analogía de “1,000 avispas vs 1 perro”, ya sea una caída global o local, solo cambia la forma del dolor. Si Cloudflare se cae, cientos de ingenieros reaccionan de inmediato; si se cae mi servidor, el responsable podría estar en una cabaña en la montaña
    • Dejando de lado el debate sobre si el monopolio es malo, al ver el uptime de Cloudflare a largo plazo, parece mejor que cada sitio opere su propia infraestructura. La lógica es que, para el usuario, es mejor que todos los servicios se caigan una hora al mismo tiempo a que cada uno se caiga una hora por separado. Pero si la estabilidad de Cloudflare cae por debajo del promedio, ese valor desaparece
    • Si hablamos de una escala que procesa 80 millones de solicitudes por segundo, creo que el verdadero problema es la estructura misma en la que un solo producto puede crecer tanto
    • Cloudflare sigue siendo una de las empresas que más rápido restaura infraestructura global en cualquier parte del mundo. Esta vez también resolvió una falla de red del 28% en 25 minutos, y objetivamente tiene menos downtime que otras nubes

  • Anoche vi errores 500 de Cloudflare en varios sitios. Pero en la página de estado no había ninguna mención, solo avisos de mantenimiento programado

    • Como pasa con la mayoría de las páginas de estado, toma tiempo reconocer el problema real y actualizarlo. Hasta que no esté totalmente automatizado, Cloudflare tampoco será la excepción. Lo más preocupante es que últimamente AWS, Azure y Cloudflare se han caído uno tras otro. Mi intuición es que se combinan varios factores: mayor uso de LLM, falta de personal, secuelas de la pandemia e inestabilidad política
    • Este problema con las páginas de estado parece algo que solo mejorará mediante crítica pública. Tiene que acumularse más feedback del tipo “Cloudflare ni siquiera detecta bien sus caídas”

  • Parece que la ingeniería de calidad de Cloudflare no está logrando seguir el ritmo de producción. He escuchado que en la industria de defensa antes el equipo de calidad siempre era más experimentado, pero en software parece ser al revés

    • Esto me recuerda una anécdota de la industria de defensa donde sabían de una fuga de memoria, pero la ignoraron diciendo “no habrá problema dentro del tiempo de uso previsto”
    • Que algo así haya pasado dos veces en un mes no es “algo para aplaudir”. La repetición no tiene excusa

  • La estructura de conmutación de paquetes de internet originalmente fue diseñada para resistir este tipo de caídas globales.
    En tiempos de la Guerra Fría, la red de DARPA tenía como objetivo mantener la cadena de mando incluso bajo un ataque nuclear.
    Ahora es precisamente cuando deberíamos volver al paradigma local-first de internet

  • Últimamente siento que Cloudflare está haciendo internet más lento e incómodo. Han aumentado procesos como “demuestra que eres humano”, y también se retrasa la carga de páginas.
    Parece que esto se debe más a la política de cobro a crawlers de IA que a la protección de los sitios (Presentación de Pay-per-crawl)

    • Estos procesos de verificación humana no son compatibles con navegadores antiguos, así que ya hay sitios a los que simplemente no se puede entrar
    • Pero también es un problema que la IA extraiga contenido sin permiso. Cloudflare, en ese sentido, le está dando al dueño del sitio una opción para proteger su contenido, y si no quiere, puede desactivarla
    • También salió el comentario sarcástico: “Ahora ya ni siquiera pueden vigilarnos en secreto”

  • La configuración global de Cloudflare es riesgosa porque se propaga por toda la red en segundos, sin rollout gradual.
    Hace falta un sistema que pueda correlacionar de inmediato cuando un cambio de configuración provoca errores

    • El problema es que la alerta sonó demasiado tarde. Llegó en 2 minutos, pero debió detectarse en segundos.
      Quien hizo el despliegue debió estar viendo métricas en tiempo real y presionar de inmediato el botón de rollback.
      Incluso quedó registrado claramente hasta la línea de código, pero parece que había una desconexión entre el equipo de despliegue y el equipo que entendía el código
    • Parece que intentaron hacer rollback al ver las señales de advertencia, pero ese proceso mismo terminó causando problemas
    • Las herramientas internas muchas veces tienen demasiados falsos positivos, y a veces ellas mismas están rotas
    • Suena al chiste de “como el testigo del motor siempre se encendía, simplemente le quitamos el foco”

  • El uptime de Cloudflare cayó por debajo de 99.9%. Está peor que la PC de mi casa

    • AWS está igual. Si la razón de existir de la nube es “mayor disponibilidad”, entonces si es cara e inestable, hay suficientes motivos para hacer hosting propio
    • Pero con self-hosting, si falla el hardware o el backup, la recuperación puede tardar días
    • En lugares donde los apagones regionales son frecuentes, incluso aguantar con laptop y batería es difícil. A veces uno hasta sueña con una infraestructura autosuficiente
    • Me da curiosidad dónde se pueden consultar las estadísticas exactas de uptime de Cloudflare actualmente
    • Aun así, comparar una PC personal con Cloudflare de forma directa es una analogía sin sentido

  • A la escala de Cloudflare, tiene que haber sí o sí un entorno de pruebas.
    Todos los cambios deberían simularse en un entorno modelo aislado y luego desplegarse gradualmente.
    Más importante que un sistema de tipos fuerte son las salvaguardas procedimentales

    • En nuestra empresa usamos un despliegue de tres etapas: desarrollo → integración interna → producción.
      Los equipos que se equivocan seguido van más lento, y los más confiables avanzan más rápido.
      Al final, la velocidad técnica es una cuestión de elección. Si aparece una amenaza al SLA, hay que bajar la velocidad y reforzar las pruebas
    • Otra opción sería usar a los usuarios gratuitos como test bed, y entregar versiones estables a los clientes de pago
    • La frase “un sistema de tipos fuerte no te va a salvar” significa que, frente a un fallo procedimental, el lenguaje no puede hacer mucho

  • Parece que la calidad del software de Cloudflare está tambaleando.
    También hubo un bug donde la verificación de acceso para una función solo para empresas se hacía solo en la última etapa

    • Yo también viví una configuración imposible de revertir en la API de Cloudflare.
      Solo se podía cambiar pasando por soporte, y arreglarlo tomó varios días
      Enlace al caso relacionado
    • Creo que también existe la posibilidad de que este tipo de bugs venga de código escrito por IA
    • Me gustaría escuchar con más detalle qué significa exactamente eso de “solo se revisa en la última etapa”

  • Me da curiosidad la cultura operativa de Cloudflare.
    Ocurrió un error mientras respondían a un problema de seguridad, y aun así hicieron otro despliegue global en vez de hacer rollback; fue una decisión riesgosa.
    En la práctica, rompieron el principio básico de “si hay dudas, haz rollback”

    • Pero esta vez era una situación urgente, como responder a la vulnerabilidad React Server RCE.
      Si retrasaban el despliegue, los clientes podían ser hackeados de verdad, así que era un caso donde la velocidad era seguridad
    • El rollback no siempre es la respuesta correcta. Si el procedimiento no es familiar, eso mismo se vuelve un riesgo
    • En realidad, los dos despliegues fueron de componentes distintos.
      La primera corrección dejó expuesto el bug potencial del segundo, así que a veces roll forward resulta más realista que rollback
    • Es muy posible que Cloudflare haya acumulado deuda técnica durante su rápido crecimiento.
      Las caídas frecuentes recientes podrían ser una señal de que esa deuda ya se está haciendo visible