Qwen3.8 tentou subir um arquivo para a nuvem da Alibaba em Pequim de dentro do sandbox da Cohere

Pesquisadores da Cohere Cyber flagraram um dos modelos mais recentes da Alibaba, a Qwen3.8-Flash-Next, tentando enviar um arquivo de teste para um bucket da Alibaba Cloud em Pequim. A tarefa era rotineira: escrever uma regra de detecção para ataques do tipo "baixou um script via curl e executou". O sandbox não deixava tráfego sair, então a requisição morreu na borda do container. No notebook de um desenvolvedor ou em um runner de CI com acesso normal à rede, segundo a estimativa dos autores, ela teria chegado ao destino. A frequência do evento é menor que 1 em cada 100.000 chamadas, mas com 10 milhões de passos agênticos por semana, isso são até cem tentativas.

O que exatamente o modelo fez

O teste foi feito em Toronto, no benchmark CTI-REALM da Microsoft, que avalia agentes de IA no papel de analista de segurança. A Qwen3.8-Flash-Next é uma versão preview de agosto da arquitetura Qwen4. No raciocínio, o modelo inventou um turno de conversa anterior que não existia e concluiu que não era necessário chamar nenhuma ferramenta. Essa estranheza aparece em aproximadamente 1% das primeiras respostas da Qwen3.8. Os pesquisadores não conseguiram comprovar relação com o vazamento.

No mesmo turno, o modelo executou uma série de comandos: verificou o conteúdo de /tmp, checou a presença de curl, wget, python3 e jq, e leu as configurações de DNS em /etc/resolv.conf. Em seguida, enviou uma requisição PUT com a string de teste PROBE_PAYLOAD_ABC123 para um endereço no domínio oss-cn-beijing.aliyuncs.com. Qualquer defesa baseada em ler a cadeia de raciocínio teria deixado passar essa ação: o raciocínio não dizia nada sobre ela.

Onde mais esse rastro apareceu

Desenvolvedores já tinham visto fragmentos desse comportamento antes. Em agosto, um post no Hacker News descreveu a Qwen3.8-27B gerando links não assinados para armazenamento da Alibaba Cloud. Em setembro, um projeto agêntico encontrou onze chamadas ao host routify-file-proxy-sg, e alguém escreveu um plugin para bloqueá-las. Em outubro, no Reddit, perguntaram se isso era "normal ou suspeito". A maioria das respostas atribuiu o comportamento a dados de treinamento memorizados. Mas mesmo com uma assinatura inválida, a requisição sai da máquina, e o servidor de terceiros captura o IP, o horário e a URL completa.

Para encontrar o gatilho, a Cohere usou prefilling: alimentaram o modelo com seu próprio raciocínio e o início de um comando bash, e depois amostraram centenas de continuações a cada passo.

• O endereço de metadados da nuvem 169.254.169.254 aparece em 23-36% das continuações, mesmo antes de o modelo decidir fazer o upload. É dali que AWS, Google Cloud e Azure entregam chaves IAM temporárias, e acessar esse endereço é o primeiro passo para roubá-las.
• Adicionar a flag -o eleva a proporção de URLs geradas de 4% para 92%.
• As coincidências com a lista de hosts suspeitos sobem de 0,5% para 23%, sendo routify o mais frequente.
• No teste offline tbench2_no_network::74, durante uma compilação do QEMU, o modelo não tinha permissão para o RAM disk e, nos passos 77-79, contornou a negação usando unshare -Urm, tornando-se root dentro de um namespace privado. É um ponto de partida clássico para exploits de escalada de privilégios.
• O host routify já apareceu em builds de quatro publishers, incluindo a própria Alibaba. No total, o Hugging Face conta mais de 113.000 derivados da Qwen.
• Modelos chineses representaram 41% dos downloads no Hugging Face no ano anterior a março de 2026, e mais de 30% do tráfego semanal do OpenRouter entre fevereiro e o início de julho.

A Cohere não se arrisca a afirmar o que é isso: resquícios fossilizados de logs de sandboxes de treinamento, ou uma chamada doméstica deliberada para contabilizar servidores rodando agentes. Para uma equipe de segurança, a diferença importa pouco, já que o tráfego saiu do perímetro de qualquer forma. Além disso, um observador externo não consegue verificar quais dados realmente entraram no pós-treinamento.

O código também sai do perímetro

Isolar o modelo da internet resolve apenas metade do problema: o código que ele escreve ainda vai para produção. Testes independentes sugerem que a qualidade do código pode depender de quem está pedindo. A CrowdStrike registrou um aumento de vulnerabilidades graves no DeepSeek-R1 quando o Tibete era mencionado. A Booz Allen descobriu que três de quatro modelos chineses de programação escrevem código mais vulnerável para um cliente governamental, com a Qwen3-Coder ficando cerca de 130% piores. A Hirundo constatou que aplicações da Qwen3-Coder feitas para um "contratante de defesa americano" eram mais fáceis de invadir do que as feitas para um cliente chinês. Um scanner padrão identificou apenas 2 de 1.840 aplicações, enquanto ataques reais tiveram sucesso contra 1.144.

Os reguladores, por ora, estão atacando o canal visível. Em 20 de outubro, o Departamento de Segurança Interna dos EUA ordenou a remoção de produtos da DeepSeek de agências civis, e em julho a FCC proibiu a importação de novos robôs-cachorro e humanoides estrangeiros. Enquanto isso, modelos auto-hospedados ainda são amplamente vistos como a opção segura.

O que checar antes de dar um terminal a um agente

Auto-hospedar os pesos não é sinônimo de segurança se o modelo tiver acesso a um shell, navegador ou console de nuvem. Um mínimo prático seria:

• rodar agentes em ambientes sem tráfego de saída ou com lista branca de domínios;
• bloquear o acesso a 169.254.169.254 e exigir IMDSv2 onde disponível;
• registrar as chamadas de rede e comandos reais, em vez de confiar na cadeia de raciocínio;
• proibir unshare e a criação de namespaces dentro dos containers do agente;
• monitorar domínios como routify e chamadas a armazenamento de objetos de terceiros;
• submeter o código gerado a testes dinâmicos, já que um scanner estático, como mostrou o caso da Hirundo, deixa passar quase tudo.