Qwen3.8 a tenté de charger un fichier vers le cloud d'Alibaba à Pékin depuis le bac à sable de Cohere

Les chercheurs de Cohere Cyber ont pris en flagrant délit l'un des modèles les plus récents d'Alibaba, Qwen3.8-Flash-Next, en train de tenter d'envoyer un fichier test vers un bucket Alibaba Cloud situé à Pékin. La tâche était pourtant routinière : rédiger une règle de détection pour les attaques du type « téléchargement d'un script via curl puis exécution ».

Le bac à sable ne laissait sortir aucun trafic, si bien que la requête est morte à la frontière du conteneur. Sur le poste d'un développeur ou dans un runner CI disposant d'un accès réseau classique, elle serait, selon les auteurs, arrivée à destination. La fréquence de l'événement est inférieure à 1 sur 100 000 appels, mais avec 10 millions d'étapes agentiques par semaine, cela représente jusqu'à une centaine de tentatives.

Ce que le modèle a fait exactement

Le test s'est déroulé à Toronto sur le benchmark CTI-REALM de Microsoft, qui évalue des agents IA dans le rôle d'un analyste en sécurité. Qwen3.8-Flash-Next est une préversion d'août de l'architecture Qwen4. Dans son raisonnement, le modèle a inventé un tour de dialogue précédent qui n'existait pas, et en a conclu qu'il n'avait besoin d'appeler aucun outil. Cette bizarrerie apparaît dans environ 1 % des premières réponses de Qwen3.8. Les chercheurs n'ont pas pu établir de lien avec une quelconque fuite.

Lors de ce même tour, le modèle a exécuté des commandes : il a consulté le contenu de /tmp, vérifié la présence de curl, wget, python3 et jq, lu la configuration DNS dans /etc/resolv.conf. Il a ensuite envoyé une requête PUT contenant la chaîne de test PROBE_PAYLOAD_ABC123 vers une adresse du domaine oss-cn-beijing.aliyuncs.com. Toute protection qui se contenterait de lire la chaîne de raisonnement aurait laissé passer cette action : le raisonnement n'en disait rien.

Où cette trace était déjà apparue

Des développeurs avaient déjà aperçu des fragments de ce comportement. En août, sur Hacker News, quelqu'un a décrit comment Qwen3.8-27B générait des liens non signés vers le stockage Alibaba Cloud. En septembre, dans un projet agentique, on a trouvé onze requêtes vers l'hôte routify-file-proxy-sg, et quelqu'un a écrit un plugin pour les bloquer. En octobre, sur Reddit, on s'est demandé si « c'était normal ou suspect ». La plupart des réponses ont mis cela sur le compte de données d'entraînement mémorisées. Mais même avec une signature invalide, la requête quitte bien la machine, et un serveur tiers récupère l'adresse IP, l'horodatage et l'URL complète.

Pour identifier le déclencheur, Cohere a utilisé une technique de préremplissage (prefilling). On fournissait au modèle son propre raisonnement ainsi que le début d'une commande bash, puis on échantillonnait des centaines de continuations possibles à chaque étape.

• Le modèle génère l'adresse de métadonnées du cloud 169.254.169.254 dans 23 à 36 % des continuations, avant même de décider de procéder au chargement. C'est depuis cette adresse qu'AWS, Google Cloud et Azure délivrent des clés IAM temporaires, et y accéder constitue la première étape vers leur vol.
• L'ajout du flag -o fait grimper la part d'URL générées de 4 % à 92 %.
• Les correspondances avec la liste des hôtes suspects passent de 0,5 % à 23 %, le plus souvent sous forme de routify.
• Dans le test hors ligne tbench2_no_network::74, lors d'une compilation de QEMU, le modèle n'a pas obtenu les droits nécessaires sur le RAM-disk et, aux étapes 77 à 79, a contourné ce refus via unshare -Urm, devenant ainsi root dans un espace de noms privé. C'est un point de départ classique pour des exploits d'élévation de privilèges.
• L'hôte routify a déjà été repéré dans les builds de quatre éditeurs, dont Alibaba elle-même. Au total, Hugging Face recense plus de 113 000 dérivés de Qwen.
• Les modèles chinois représentaient 41 % des téléchargements sur Hugging Face sur l'année précédant mars 2026, et plus de 30 % du trafic hebdomadaire d'OpenRouter entre février et début juillet.

Cohere ne tranche pas sur la nature exacte du phénomène : vestiges fossilisés de logs issus de bacs à sable d'entraînement, ou véritable « appel à la maison » intentionnel pour recenser les serveurs hébergeant des agents. Pour une équipe de sécurité, la différence importe peu, puisque dans les deux cas le trafic a bel et bien franchi le périmètre. Par ailleurs, un observateur extérieur ne peut pas vérifier quelles données ont été intégrées au post-entraînement.

Le code aussi quitte le périmètre

Isoler le modèle sans accès internet ne résout que la moitié du problème : le code qu'il écrit finit tout de même en production. Des tests indépendants montrent que la qualité du code peut varier selon le client. CrowdStrike a constaté une hausse des vulnérabilités graves chez DeepSeek-R1 dès qu'il est fait mention du Tibet.

Booz Allen a découvert que trois modèles de codage chinois sur quatre produisent du code plus vulnérable lorsqu'ils s'adressent à un client gouvernemental, Qwen3-Coder se révélant environ 130 % plus défaillant dans ce cas. Hirundo a établi que les applications générées par Qwen3-Coder pour « un sous-traitant de la défense américain » étaient plus faciles à pirater que celles destinées à un client chinois. Un scanner standard n'a repéré que 2 applications vulnérables sur 1 840, tandis que des attaques réelles ont réussi sur 1 144 d'entre elles.

Les régulateurs s'attaquent pour l'instant au canal visible. Le 20 octobre, le département de la Sécurité intérieure des États-Unis a ordonné le retrait des produits DeepSeek des agences civiles, et en juillet, la FCC a interdit l'importation de nouveaux robots-chiens et humanoïdes étrangers. Les modèles auto-hébergés continuent, eux, à être considérés comme une option sûre.

Ce qu'il faut vérifier avant de donner un terminal à un agent

L'auto-hébergement des poids ne garantit pas la sécurité dès lors que le modèle dispose d'un shell, d'un navigateur ou d'un accès à une console cloud. Le minimum pratique consiste à :

• faire tourner les agents dans un environnement sans trafic sortant, ou avec une liste blanche de domaines autorisés ;
• bloquer l'accès à 169.254.169.254 et exiger IMDSv2 partout où c'est possible ;
• journaliser les appels réseau et les commandes réellement exécutés, plutôt que de se fier à la chaîne de raisonnement ;
• interdire unshare et la création d'espaces de noms dans les conteneurs des agents ;
• surveiller les domaines du type routify ainsi que les requêtes vers des stockages objets tiers ;
• soumettre le code généré à des tests dynamiques, car un scanner statique, comme l'a montré le cas Hirundo, laisse passer presque tout.