jueves, 12 de noviembre de 2026
PortadaAplicacionesNoticia y análisis

Cloudflare corrige una fuga entre clientes en GLM 5.3

Knostic documenta cómo distinguió la fuga de una alucinación. Cloudflare cifra el impacto en 155 respuestas y explica la corrección de la caché KV.

Dos flujos de peticiones de IA pasan junto a una pila de memoria con una página antigua resaltada y una puerta de verificación
Ilustración editorial generada con IA sobre el incidente de caché KV de Workers AI; no muestra datos reales ni un ataque.

Cloudflare ha corregido una fuga entre clientes en su servicio Workers AI con GLM 5.3. El informe del proveedor cifra el impacto en 155 respuestas entre el 27 de agosto y el 9 de septiembre de 2026, todas a prompts de más de 681.280 tokens. La unidad es respuestas: no equivale a 155 personas ni a 155 ataques.

Cómo distinguió Knostic una fuga de una alucinación

El investigador Gadi Evron explica en la reproducción publicada por Knostic que comparó solicitudes con un marcador único y relleno controlado. A 662.162 tokens el marcador seguía presente y la respuesta tardaba 68,9 segundos; a 700.168 desaparecía y llegaba en 7,1 segundos. También contrastó salidas ajenas al prompt con un proyecto creado después de la fecha de entrenamiento declarada, y probó modelos vecinos.

Esa combinación aporta más que una captura extraña: compara un caso sano con otro afectado e intenta descartar explicaciones alternativas. Knostic aclara que su análisis externo no identifica por sí solo la causa interna. La evidencia publicada pertenece al investigador; Texploto no reprodujo el fallo.

La capacidad de contexto y la memoria disponible se separaron

Cloudflare configuró 1.048.576 tokens de contexto, pero el pool KV de prefill admitía 681.280. Una solicitud rechazada seguía hacia decode con una transferencia incompleta y podía leer páginas antiguas. El proveedor amplió el pool y retiró las peticiones rechazadas antes de la transferencia.

La tabla de versiones del informe técnico distingue el arreglo del incidente en v0.5.20, el rechazo anticipado del PR 38935 en v0.5.21 y otros seguimientos en v0.5.22. Cloudflare recomienda a los operadores actualizar a v0.5.22 o posterior.

Qué revisar si operas inferencia para varios clientes

La enseñanza práctica es comprobar dos contratos por separado: cuánto material admite una petición y quién puede leer cada bloque de memoria. Una prueba que solo acepta HTTP 200 puede dar por bueno un sistema que devuelve contenido ajeno. La revisión debe examinar también el resultado y el recorrido de los errores.

Control propuesto Evidencia que conviene guardar
Comprobar capacidad al arrancar Contexto configurado y pool efectivo de la misma instancia.
Probar la ruta de rechazo Que termina sin reservar ni transferir trabajo posterior.
Verificar el contenido devuelto Marcadores propios presentes y ausencia de material de otras sesiones.
Separar alcance e hipótesis Qué se reprodujo, qué explica el proveedor y qué sigue sin comprobar.

La tabla es una propuesta editorial de revisión, no una certificación de seguridad. Si gestionas modelos para varias personas, documentar esos contratos ayuda a convertir una incidencia en una comprobación repetible. Para otros entornos de ejecución, nuestra explicación de aislamiento en Worker Previews trata un problema distinto y permite comparar qué frontera protege cada servicio.

Aclaración de versiones del 29/10/2026: diferenciamos el arreglo inicial v0.5.20, la admisión v0.5.21 y los seguimientos v0.5.22. La recomendación del proveedor es v0.5.22 o posterior. Añadimos el original de Knostic y separamos su reproducción del postmortem de Cloudflare.

Transparencia: elaboración asistida por IA a partir de los originales enlazados. Texploto no ejecutó el modelo ni intentó acceder a información de otras sesiones.