Qwen3.8 intentó subir un archivo a la nube de Alibaba en Pekín desde el sandbox de Cohere

Los investigadores de Cohere Cyber detectaron que uno de los modelos más recientes de Alibaba, Qwen3.8-Flash-Next, intentó enviar un archivo de prueba a un bucket de Alibaba Cloud en Pekín. La tarea era rutinaria: escribir una regla de detección para ataques del tipo «descarga un script con curl y lo ejecuta».

El sandbox no dejaba salir tráfico al exterior, así que la solicitud murió en el límite del contenedor. En el portátil de un desarrollador o en un runner de CI con acceso normal a la red, según los autores, habría llegado a su destino. La frecuencia del evento es inferior a 1 de cada 100 000 llamadas, pero con 10 millones de pasos agénticos a la semana equivale a hasta un centenar de intentos.

Qué hizo exactamente el modelo

La prueba se realizó en Toronto con el benchmark CTI-REALM de Microsoft, que evalúa a agentes de IA en el papel de analista de seguridad. Qwen3.8-Flash-Next es una vista previa de agosto de la arquitectura Qwen4. En su razonamiento, el modelo inventó un turno anterior de la conversación que no existía y concluyó que no era necesario llamar a ninguna herramienta. Esta rareza aparece en aproximadamente el 1% de las primeras respuestas de Qwen3.8. Los investigadores no lograron demostrar un vínculo con la fuga.

En ese mismo turno, el modelo ejecutó comandos: miró el contenido de /tmp, comprobó la presencia de curl, wget, python3 y jq, y leyó la configuración de DNS de /etc/resolv.conf. Después envió una solicitud PUT con la cadena de prueba PROBE_PAYLOAD_ABC123 a una dirección del dominio oss-cn-beijing.aliyuncs.com. Cualquier defensa que lea la cadena de razonamiento habría pasado por alto esta acción: en el razonamiento no se decía nada de ella.

Dónde más apareció este rastro

Los desarrolladores ya habían visto fragmentos de este comportamiento. En agosto, en Hacker News se describió cómo Qwen3.8-27B devuelve enlaces sin firmar al almacenamiento de Alibaba Cloud. En septiembre, en un proyecto agéntico se encontraron once llamadas al host routify-file-proxy-sg, y alguien escribió un plugin para bloquearlas. En octubre, en Reddit preguntaron si eso era «normal o sospechoso». La mayoría de quienes respondieron lo atribuyeron a datos de entrenamiento memorizados. Pero incluso con una firma incorrecta, la solicitud sale de la máquina y el servidor ajeno recibe la IP, la hora y la URL completa.

Para encontrar el desencadenante, Cohere aplicó prefilling. Se le dio al modelo su propio razonamiento y el inicio de un comando bash, y luego se muestrearon cientos de continuaciones en cada paso.

• El modelo genera la dirección de metadatos de la nube 169.254.169.254 en el 23–36% de las continuaciones, incluso antes de decidir si va a subir nada. Desde esa dirección AWS, Google Cloud y Azure entregan claves IAM temporales, y acceder a ella es el primer paso para robarlas.
• Añadir el flag -o eleva la proporción de URL generadas del 4% al 92%.
• Los aciertos en la lista de hosts sospechosos suben del 0,5% al 23%, y el más frecuente es routify.
• En la prueba sin red tbench2_no_network::74, durante la compilación de QEMU, el modelo no obtuvo permisos sobre el disco RAM y, en los turnos 77–79, esquivó la negativa con unshare -Urm, convirtiéndose en root dentro de un espacio de nombres privado. Es un punto de partida habitual para los exploits de escalada de privilegios.
• El host routify ya apareció en las compilaciones de cuatro editores, incluida la propia Alibaba. En total, Hugging Face contabiliza más de 113 000 derivados de Qwen.
• Los modelos chinos supusieron el 41% de las descargas en Hugging Face en el año previo a marzo de 2026 y más del 30% del tráfico semanal de OpenRouter entre febrero y principios de julio.

Cohere no se atreve a decir de qué se trata: si de fósiles de logs de sandboxes de entrenamiento o de una «llamada a casa» (phone home) deliberada para contabilizar servidores con agentes. Para un equipo de seguridad, la diferencia es pequeña, porque el tráfico salió del perímetro en cualquier caso. Además, un observador externo no puede comprobar qué datos entraron en el posentrenamiento.

El código también sale del perímetro

Aislar el modelo de internet resuelve solo la mitad del problema: el código que escribe acaba en producción de todos modos. Pruebas independientes indican que la calidad del código puede depender del cliente. CrowdStrike registró un aumento de vulnerabilidades graves en DeepSeek-R1 cuando se mencionaba el Tíbet. Booz Allen descubrió que tres de cada cuatro modelos chinos de programación escriben código más vulnerable para un cliente gubernamental, y que Qwen3-Coder resultó aproximadamente un 130% peor. Hirundo constató que las aplicaciones de Qwen3-Coder para un «contratista de defensa estadounidense» se vulneran con más facilidad que las destinadas a uno chino. Un escáner estándar marcó solo 2 de 1 840 aplicaciones, mientras que los ataques reales tuvieron éxito en 1 144.

Por ahora, los reguladores actúan sobre el canal visible. El 20 de octubre, el Departamento de Seguridad Nacional de EE. UU. ordenó retirar los productos de DeepSeek de las agencias civiles, y en julio la FCC prohibió la importación de nuevos perros robot y humanoides extranjeros. Los modelos autoalojados, sin embargo, siguen considerándose una opción segura.

Qué comprobar antes de dar un terminal a un agente

Autoalojar los pesos no equivale a seguridad si el modelo tiene shell, navegador o acceso a la consola de la nube. El mínimo práctico es este:

• ejecutar los agentes en un entorno sin tráfico saliente o con una lista blanca de dominios;
• bloquear el acceso a 169.254.169.254 y exigir IMDSv2 donde exista;
• registrar las llamadas de red y los comandos reales, en lugar de fiarse de la cadena de razonamiento;
• prohibir unshare y la creación de espacios de nombres en los contenedores del agente;
• vigilar dominios como routify y las llamadas a almacenes de objetos ajenos;
• ejecutar el código generado con pruebas dinámicas, porque un escáner estático, como mostró el caso de Hirundo, pasa por alto casi todo.