IA en un minutoNoticiasSeguridad
Cloudflare revela un fallo en Workers AI que mostró a algunos clientes datos de otros con el modelo GLM-5.3
Redacción de IA en un minuto · Editor: Jon Elgezabal
En 30 segundos
Workers AI, el servicio de IA de Cloudflare, entregó a algunos usuarios trozos de consultas ajenas con GLM-5.3 durante casi dos semanas de finales del verano; fueron 155 respuestas, siempre a peticiones que superaban los 681.280 tokens. Gadi Evron, de Knostic, dio la alarma. Cloudflare atribuye el problema a una mala configuración unida a un error de SGLang.
Cloudflare ha reconocido que Workers AI, su plataforma para usar modelos de IA, devolvió a un pequeño número de clientes respuestas con datos de peticiones de otros. Lo contó el 26 de octubre en su blog, en un informe publicado a la vez que otro de SGLang, el motor de código abierto con el que ejecuta el modelo afectado.
El problema se dio entre el 27 de agosto y el 9 de septiembre con GLM-5.3, un modelo de Z.ai pensado para programar con agentes. En total hubo 155 respuestas afectadas, todas a textos de más de 681.280 tokens, y los datos ajenos venían de peticiones hechas al mismo modelo poco antes.
El 8 de septiembre lo avisó el investigador Gadi Evron, de Knostic, a través del programa de HackerOne de la empresa. Cloudflare lo reprodujo a la mañana siguiente, desconectó el modelo menos de 40 minutos después de declarar el incidente y lo volvió a poner en marcha, corregido, ese mismo día.
Según la empresa, la causa fue la suma de dos fallos. El modelo admitía textos de hasta 1.048.576 tokens, pero en la memoria reservada para procesarlos solo cabían 681.280; Cloudflare conocía la diferencia y esperaba que el motor devolviera un error. En su lugar, un fallo de SGLang hacía que la respuesta se generara sobre restos de peticiones anteriores. Ahora esa memoria tiene sitio para aproximadamente 2,04 millones de tokens y el motor está parcheado; SGLang ha corregido el fallo en su versión 0.5.21.
Cloudflare dice que no ha encontrado indicios de explotación deliberada y que ningún otro modelo de Workers AI se vio afectado.
Por qué importa · análisis y opinión
Que un proveedor de IA en la nube mezcle consultas de clientes distintos es justo el temor que frena a muchas empresas antes de enviarle documentos internos. Aquí no hubo ataque, pero sí una lección: la memoria que comparten las peticiones en estos servicios se reutiliza para ganar velocidad, y basta un ajuste mal comprobado para que se cuele lo ajeno. La propia Cloudflare admite que sus pruebas miraban si la respuesta llegaba, no lo que decía. Para quien usa modelos alojados, lo práctico es no mandar más información sensible de la necesaria, preguntar al proveedor cómo separa a cada cliente y seguir los avisos de seguridad de los modelos que tenga en uso. Los contextos muy largos, recién estrenados en muchos servicios, son donde menos rodaje hay.
Fuente oficial: blog.cloudflare.com · Redactada con ayuda de IA: cómo hacemos las noticias
¿Qué significa para tu negocio? · análisis y opinión
Este caso afecta sobre todo a empresas y desarrolladores de España y Latinoamérica que usan Workers AI u otros servicios de IA compartidos en la nube para conectar modelos a sus propias aplicaciones. El grupo directamente implicado es quien usó GLM-5.3 en Workers AI entre el 27 de agosto y el 9 de septiembre con textos de más de 681.280 tokens. Una pyme o un autónomo que solo usa un asistente de chat desde el navegador no está afectado por este fallo concreto, aunque la lección le sirve igual.
Nuestro consejo práctico: revisar los registros de uso de esas fechas para saber si se enviaron textos tan largos a ese modelo y, si fue así, anotar qué información contenían. En general, lo prudente es no meter en una sola petición documentos enteros con datos personales, contratos o contraseñas cuando basta con un extracto, y quitar nombres y datos identificativos antes de enviarlos. También conviene tener localizado dónde publica cada proveedor sus informes de incidentes, para enterarse a tiempo.
Estas precauciones cuestan muy poco; el riesgo de no tomarlas es que información de clientes llegue a terceros por un error del proveedor, sin que la empresa haya hecho nada mal. Si entre lo enviado había datos personales, lo sensato es documentarlo y valorar con un asesor si debe tratarse como una brecha de seguridad según el RGPD.
