El 18 de noviembre de 2025, la red de Cloudflare experimentó fallos importantes en la entrega de tráfico de red durante aproximadamente dos horas y diez minutos. Casi tres semanas después, el 5 de diciembre de 2025, nuestra red volvió a dejar de atender el tráfico del 28 % de las aplicaciones detrás de nuestra red durante unos 25 minutos.
Publicamos entradas de blog detalladas sobre los análisis post mortem después de ambos incidentes, pero sabemos que tenemos que hacer más para recuperar tu confianza. Hoy compartimos detalles sobre el trabajo en curso en Cloudflare para evitar que se repitan interrupciones como estas.
Hemos llamado al plan “Código Naranja: fallar en pequeño”, que refleja nuestro objetivo de hacer que nuestra red sea más resistente a los errores o equivocaciones que podrían provocar una interrupción importante. Un “Código naranja” significa que el trabajo en este proyecto tiene prioridad sobre todo lo demás. Para dar contexto, declaramos un “Código Naranja” en Cloudflare una vez antes, tras otro incidente importante que requirió la máxima prioridad de todos en la empresa. Consideramos que los acontecimientos recientes requieren la misma atención. Código Naranja es nuestra forma de permitir que eso suceda, permitiendo que los equipos trabajen de forma interfuncional según sea necesario para realizar el trabajo, mientras se pausa cualquier otro trabajo.
El trabajo del Código naranja se organiza en tres áreas principales:
Requerir implementaciones controladas para cualquier cambio de configuración que se propague a la red, tal como lo hacemos actualmente para las versiones binarias de software.
Revisar, mejorar y probar los modos de fallo de todos los sistemas que gestionan el tráfico de red para garantizar que presenten un comportamiento bien definido en todas las condiciones, incluidas las situaciones de error inesperadas.
Cambiar nuestros procedimientos internos de "romper el vidrio"* y eliminar cualquier dependencia circular para que nosotros y nuestros clientes podamos actuar con rapidez y acceder a todos los sistemas sin problemas durante un incidente.
Estos proyectos ofrecerán mejoras iterativas a medida que avancen, en lugar de un cambio "radical" al final. Cada actualización individual contribuirá a una mayor resiliencia en Cloudflare. Para cuando esto termine, esperamos que la red de Cloudflare sea mucho más resiliente, incluso ante problemas como los que provocaron los incidentes globales que experimentamos en los últimos dos meses.
Entendemos que estos incidentes son dolorosos para nuestros clientes y para Internet en su conjunto. Nos sentimos profundamente avergonzados por ello, por lo que este trabajo es la principal prioridad para todos aquí en Cloudflare.
* Los procedimientos de Romper el vidrio en Cloudflare permiten a ciertas personas elevar sus privilegios bajo ciertas circunstancias para realizar acciones urgentes con el fin de resolver escenarios de alta gravedad.
En el primer incidente, los usuarios que visitaban el sitio de un cliente en Cloudflare vieron páginas de error que indicaban que Cloudflare no podía entregar una respuesta a su solicitud. En el segundo caso, vieron páginas en blanco.
Ambas interrupciones siguieron un patrón similar. En los momentos previos a cada incidente, implementamos de forma instantánea un cambio de configuración en nuestros centros de datos ubicados en cientos de ciudades de todo el mundo.
El cambio de noviembre consistió en una actualización automática de nuestro clasificador de gestión de bots. Ejecutamos varios modelos de inteligencia artificial que aprenden del tráfico que fluye a través de nuestra red para crear detecciones que identifican bots. Actualizamos constantemente esos sistemas para mantenernos un paso adelante de los agentes maliciosos que intentan eludir nuestra protección de seguridad y llegar a los sitios de los clientes.
Durante el incidente de diciembre, mientras intentábamos proteger a nuestros clientes de una vulnerabilidad en el popular marco de código abierto React, implementamos un cambio en una herramienta de seguridad que utilizan nuestros analistas de seguridad para mejorar nuestras firmas. De forma similar a la urgencia de las nuevas actualizaciones de gestión de bots, necesitábamos anticiparnos a los atacantes que querían aprovechar la vulnerabilidad. Ese cambio provocó el inicio del incidente.
Este patrón reveló una deficiencia importante en la forma en que implementamos los cambios de configuración en Cloudflare, en comparación con la forma en que lanzamos las actualizaciones de software. Cuando lanzamos actualizaciones de versiones de software, lo hacemos de manera controlada y supervisada. Para cada nueva versión binaria, la implementación debe completar con éxito varias etapas antes de poder servir tráfico a nivel mundial. Primero implementamos la función para el tráfico de empleados, antes de implementar cuidadosamente el cambio a porcentajes cada vez mayores de clientes en todo el mundo, comenzando con los usuarios gratuitos. Si detectamos una anomalía en cualquier etapa, podemos revertir la publicación sin intervención humana.
No hemos aplicado esa metodología a los cambios de configuración. A diferencia de la publicación del software central que impulsa nuestra red, cuando realizamos cambios de configuración, modificamos los valores de cómo se comporta ese software y podemos hacerlo al instante. También damos este poder a nuestros clientes: si realizas un cambio en una configuración de Cloudflare, se propagará globalmente en segundos.
Si bien esa velocidad tiene ventajas, también implica riesgos que debemos abordar. Los dos últimos incidentes han demostrado que debemos tratar cualquier cambio que se aplique a la forma en que servimos el tráfico en nuestra red con el mismo nivel de precaución probada que aplicamos a los cambios en el propio software.
Nuestra capacidad de implementar cambios de configuración globalmente en segundos fue la principal característica común en los dos incidentes. En ambos casos, una configuración errónea interrumpió nuestra red en segundos.
La introducción de implementaciones controladas de nuestra configuración, tal como ya lo hacemos para las versiones de software, es el flujo de trabajo más importante de nuestro plan Código naranja.
Los cambios de configuración en Cloudflare se propagan a la red muy rápidamente. Cuando un usuario crea un nuevo registro DNS o crea una nueva regla de seguridad, esta llega al 90 % de los servidores de la red en cuestión de segundos. Está impulsado por un componente de software que llamamos internamente Quicksilver.
Quicksilver también se usa para cualquier cambio de configuración que requieran nuestros propios equipos. La velocidad es una característica: podemos reaccionar y actualizar globalmente el comportamiento de nuestra red con mucha rapidez Sin embargo, en ambos incidentes, esto provocó que un cambio crítico se propagara a toda la red en segundos, en lugar de pasar por las puertas para probarlo.
Si bien la capacidad de implementar cambios en nuestra red de forma casi instantánea es útil en muchos casos, rara vez es necesaria. Se está trabajando para tratar la configuración de la misma manera en que tratamos el código, introduciendo implementaciones controladas dentro de Quicksilver para cualquier cambio en la configuración.
Publicamos actualizaciones de software en nuestra red varias veces al día mediante lo que llamamos nuestro sistema de Implementación mediada por estado (HMD). En este marco, cada equipo de Cloudflare que posee un servicio (una pieza de software implementada en nuestra red) debe definir las métricas que indican si una implementación se realizó correctamente o no, el plan de implementación y los pasos a seguir en caso de que no se concrete.
Los diferentes servicios tendrán variables ligeramente distintas. Algunos podrían necesitar tiempos de espera más prolongados antes de proceder a más centros de datos, mientras que otros podrían tener tolerancias más bajas para las tasas de error, incluso si esto provoca señales de falsos positivos.
Una vez implementado, nuestro kit de herramientas HMD comienza a avanzar cuidadosamente según ese plan, supervisando cada paso antes de continuar. Si falla algún paso, la reversión comenzará automáticamente y se notificará al equipo si es necesario.
Al final del Código naranja, las actualizaciones de configuración seguirán el mismo proceso. Esperamos que esto nos permita detectar rápidamente los tipos de problemas que ocurrieron en los dos incidentes pasados, mucho antes de que se conviertan en problemas generalizados.
¿Cómo abordaremos los modos de fallo entre servicios?
Si bien somos optimistas de que un mejor control sobre los cambios de configuración detectará más problemas antes de que se conviertan en incidentes, sabemos que los errores pueden ocurrir y ocurrirán. Durante ambos incidentes, los errores en una parte de nuestra red causaron problemas en la mayor parte de nuestra pila tecnológica, incluido el plano de control que los clientes utilizan para configurar Cloudflare.
Necesitamos pensar en implementaciones cuidadosas y graduales, no solo en términos de progresión geográfica (que se extienda a más de nuestros centros de datos) o en términos de progresión de la población (que se extienda a empleados y tipos de clientes). También debemos planificar implementaciones más seguras que contengan fallos derivados de la progresión del servicio (propagándose desde un producto, como nuestro servicio de gestión de bots, a otro no relacionado, como nuestro panel de control).
Con ese fin, estamos en el proceso de revisar los contratos de interfaz entre cada producto y servicio crítico que comprende nuestra red para asegurarnos de que a) asumamos que se producirán fallas entre cada interfaz y b) manejemos esas fallas de la manera más razonable posible.
Volviendo a la falla de nuestro servicio de gestión de bots, hubo al menos dos interfaces clave en las que, si hubiéramos asumido que la falla iba a ocurrir, podríamos haberla gestionado de manera adecuada hasta el punto de que era poco probable que algún cliente se viera afectado. La primera fue en la interfaz que leía el archivo de configuración dañado. En lugar de entrar en pánico, debió existir un conjunto sensato de valores predeterminados validados que permitieran que el tráfico pasara por nuestra red; en el peor de los casos, habríamos perdido el ajuste en tiempo real que alimenta nuestros modelos de aprendizaje automático para la detección de bots.
La segunda interfaz se encontraba entre el software central que ejecuta nuestra red y el módulo de gestión de bots. En caso de que nuestro módulo de gestión de bots fallara (como lo hizo), no debimos descartar el tráfico de forma predeterminada. En cambio, podríamos haber propuesto, una vez más, una opción predeterminada más sensata que permitiera el paso del tráfico con una clasificación aceptable.
¿Cómo podemos resolver las emergencias más rápido?
Durante los incidentes, nos tomó demasiado tiempo resolver el problema. En ambos casos, esta situación se agravó debido a que nuestros sistemas de seguridad impedían que los miembros del equipo accedieran a las herramientas necesarias para solucionar el problema. Además, en algunos casos, las dependencias circulares nos ralentizaron, ya que algunos sistemas internos también dejaron de estar disponibles.
Como empresa de seguridad, todas nuestras herramientas están protegidas mediante capas de autenticación con controles de acceso pormenorizados para garantizar la seguridad de los datos de clientes y evitar el acceso no autorizado. Esto es lo correcto, pero, al mismo tiempo, nuestros procesos y sistemas actuales nos ralentizaban cuando la velocidad era una prioridad máxima.
Las dependencias circulares también afectaron a la experiencia del cliente. Por ejemplo, durante el incidente del 18 de noviembre, Turnstile, nuestra solución de bot sin CAPTCHA, dejó de estar disponible. Como usamos Turnstile en el flujo de inicio de sesión del panel de control de Cloudflare, los clientes que no tenían sesiones activas o tokens de servicio de API no pudieron iniciar sesión en Cloudflare en el momento en que más necesitaban realizar cambios críticos.
Nuestro equipo revisará y mejorará todos los procedimientos y la tecnología de Romper el vidrio para garantizar que, cuando sea necesario, podamos acceder a las herramientas adecuadas lo más rápido posible, manteniendo a la vez nuestros requisitos de seguridad. Esto incluye revisar y eliminar las dependencias circulares, o ser capaces de "eludirlas" rápidamente en caso de que haya un incidente. También aumentaremos la frecuencia de nuestros ejercicios de capacitación para que todos los equipos comprendan bien los procesos antes de que se presente cualquier posible escenario de desastre en el futuro.
Si bien no hemos incluido en esta publicación todo el trabajo que se está llevando a cabo internamente, los flujos de trabajo detallados anteriormente describen las principales prioridades en las que se les pide a los equipos que se centren. Cada uno de estos flujos de trabajo se corresponde con un plan detallado que involucra a casi todos los equipos de producto e ingeniería de Cloudflare. Tenemos mucho trabajo que hacer.
Para fines del primer trimestre, y en gran parte antes de ese momento, nosotros:
Aseguraremos que todos los sistemas de producción estén cubiertos por implementaciones mediadas por estado (HMD) para la gestión de la configuración.
Actualizaremos nuestros sistemas para que se adhieran a los modos de fallo adecuados, según corresponda a cada conjunto de productos.
Aseguraremos que existan procesos para que las personas correctas tengan el acceso adecuado para proporcionar la remediación adecuada durante una emergencia.
Algunos de estos objetivos serán permanentes. Siempre necesitaremos gestionar mejor las dependencias circulares a medida que lancemos nuevo software, y nuestros procedimientos de emergencia deberán actualizarse para reflejar cómo cambia nuestra tecnología de seguridad con el tiempo.
Les fallamos a nuestros usuarios y a Internet en su conjunto en estos dos incidentes pasados. Tenemos trabajo por hacer para arreglarlo. Planeamos compartir actualizaciones a medida que este trabajo avance y agradecemos las preguntas y los comentarios que hemos recibido de nuestros clientes y socios.