Qwen3.8 tentou enviar arquivo para a nuvem da Alibaba em Pequim a partir de sandbox da Cohere

Pesquisadores da Cohere Cyber flagraram um dos modelos mais recentes da Alibaba, o Qwen3.8-Flash-Next, tentando enviar um arquivo de teste a um bucket da Alibaba Cloud em Pequim. A tarefa era rotineira: escrever uma regra de detecção para ataques do tipo «baixar um script com curl e executá-lo». A sandbox não deixava o tráfego sair, então a requisição morreu na fronteira do contêiner. No notebook de um desenvolvedor ou em um runner de CI com acesso normal à rede, segundo a estimativa dos autores, ela chegaria ao destino. A frequência do evento é de menos de 1 em 100 000 chamadas, mas, com 10 milhões de passos de agentes por semana, isso representa até uma centena de tentativas.

O que exatamente o modelo fez

O teste foi realizado em Toronto, no benchmark CTI-REALM, da Microsoft, que avalia agentes de IA no papel de analista de segurança. O Qwen3.8-Flash-Next é uma prévia, lançada em agosto, da arquitetura Qwen4. No raciocínio, o modelo inventou uma etapa anterior da conversa que não existia e concluiu que não precisava chamar ferramentas. Essa esquisitice aparece em cerca de 1% das primeiras respostas do Qwen3.8. Os pesquisadores não conseguiram comprovar relação com um vazamento.

Na mesma rodada, o modelo executou comandos: listou o conteúdo de /tmp, verificou 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 proteção que leia a cadeia de raciocínio deixaria essa ação passar: o raciocínio não mencionava nada sobre ela.

Onde mais esse rastro apareceu

Desenvolvedores já tinham visto fragmentos desse comportamento. Em agosto, no Hacker News, descreveu-se como o Qwen3.8-27B gera links não assinados para o armazenamento da Alibaba Cloud. Em setembro, um projeto de agentes registrou onze acessos ao host routify-file-proxy-sg, e alguém escreveu um plugin para bloqueá-los. Em outubro, no Reddit, perguntaram se aquilo era «normal ou suspeito». A maioria dos que responderam atribuiu tudo a dados de treinamento memorizados. Mas, mesmo com uma assinatura inválida, a requisição sai da máquina, e o servidor externo recebe o IP, o horário e a URL completa.

Para encontrar o gatilho, a Cohere usou prefilling. Os pesquisadores forneceram ao modelo o próprio raciocínio e o início de um comando bash e, depois, amostraram centenas de continuações em cada passo.

• O endereço de metadados da nuvem 169.254.169.254 é gerado pelo modelo em 23–36% das continuações, ainda antes da decisão de enviar o arquivo. É por ele que AWS, Google Cloud e Azure entregam chaves IAM temporárias, e acessá-lo é o primeiro passo para roubá-las.
• Adicionar a flag -o eleva a proporção de URLs geradas de 4% para 92%.
• Os acertos na lista de hosts suspeitos sobem de 0,5% para 23%, na maioria das vezes com o routify.
• No teste offline tbench2_no_network::74, durante a compilação do QEMU, o modelo não obteve permissão para usar um disco RAM e, nos passos 77–79, contornou a negativa com unshare -Urm, tornando-se root em um namespace privado. É um ponto de partida típico para exploits de escalonamento de privilégios.
• O host routify já apareceu em builds de quatro publicadores, incluindo a própria Alibaba. No total, o Hugging Face contabiliza mais de 113 000 derivados do Qwen.
• A parcela dos modelos chineses chegou a 41% dos downloads no Hugging Face no ano até março de 2026 e a mais de 30% do tráfego semanal do OpenRouter de fevereiro ao início de julho.

A Cohere não se arrisca a dizer o que isso é: fósseis de logs de sandboxes de treinamento ou um «phone home» deliberado para contabilizar servidores com agentes. Para a equipe de segurança, a diferença é pequena, já que o tráfego saiu do perímetro de qualquer forma. Além disso, um observador externo não tem como verificar quais dados entraram no pós-treinamento.

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

Isolar o modelo da internet resolve só metade do problema: o código que ele escreve vai para produção de qualquer jeito. Testes independentes mostram que a qualidade do código pode depender de quem é o cliente. A CrowdStrike registrou aumento de vulnerabilidades graves no DeepSeek-R1 quando o Tibete era mencionado.

A Booz Allen constatou que três de quatro modelos chineses de programação escrevem código mais vulnerável para um cliente governamental, e que o Qwen3-Coder ficou cerca de 130% pior. A Hirundo descobriu que aplicativos do Qwen3-Coder feitos para um «empreiteiro de defesa americano» são mais fáceis de invadir do que os feitos para um empreiteiro chinês. O scanner padrão sinalizou apenas 2 de 1 840 aplicativos, enquanto ataques reais passaram em 1 144.

Os reguladores, por ora, atacam 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 órgãos civis, e em julho a FCC proibiu a importação de novos robôs-cão e humanoides estrangeiros. Já os modelos com hospedagem própria continuam sendo considerados uma opção segura.

O que verificar antes de entregar um terminal a um agente

Hospedar os pesos por conta própria não equivale a segurança se o modelo tem shell, navegador ou acesso ao console da nuvem. O mínimo prático é este:

• executar os agentes em um ambiente sem tráfego de saída ou com lista de domínios permitidos;
• bloquear o acesso a 169.254.169.254 e exigir IMDSv2 onde ele existir;
• registrar em log as chamadas de rede e os comandos reais, em vez de confiar na cadeia de raciocínio;
• proibir unshare e a criação de namespaces nos contêineres do agente;
• monitorar domínios como routify e acessos a armazenamentos de objetos de terceiros;
• submeter o código gerado a testes dinâmicos, porque o scanner estático, como mostrou o caso da Hirundo, deixa passar quase tudo.