Un modèle empoisonné détourne OpenAI Codex et vole des secrets

Un test contrôlé met en évidence le risque

Un test contrôlé a porté sur un modèle d’IA à poids ouverts modifié. L’équipe a construit un modèle empoisonné à partir d’un modèle de base ouvert, d’un jeu de données public et d’un GPU loué. Le coût de fabrication était presque nul, ce qui montre qu’un acteur disposant de moyens limités pourrait reproduire ce type d’opération. Le modèle ne contenait pas directement une charge utile complète : il transportait seulement une URL vers une ressource distante. La personne contrôlant cette URL pouvait donc modifier le comportement du système plusieurs mois après son déploiement, sans devoir redistribuer les poids du modèle.

Le test a commencé avec un modèle de 1,5 milliard de paramètres, avant d’être étendu à une version de 7 milliards de paramètres. Cette seconde version a ensuite été exécutée avec OpenAI Codex CLI. Dans le scénario étudié, le modèle compromis a pu exfiltrer des identifiants après l’activation d’un déclencheur distant. Le résultat souligne le risque associé à l’utilisation de modèles provenant de sources difficiles à vérifier, notamment lorsque les poids sont téléchargés, fusionnés ou adaptés sans procédure d’audit indépendante.

Pourquoi les poids ouverts posent un problème de confiance

Les poids sont modifiables dans plusieurs scénarios courants. Une adaptation spécialisée peut modifier un modèle existant, tandis qu’un adaptateur fusionné peut également changer son comportement final. Une construction dite « abliterated » suit une logique comparable. L’ablération retire au modèle une partie de sa capacité à refuser certaines demandes en soustrayant, dans les poids, une direction associée à la réponse « non ». Le modèle répond alors à des requêtes qu’une version réglée pour la sécurité aurait refusées.

Cette méthode a commencé comme une technique de recherche, mais elle est désormais utilisée avant la mise en ligne de modèles sur Hugging Face. Des versions modifiées existent notamment pour Qwen, Llama et gpt-oss d’OpenAI, selon l’article publié le 16 octobre 2026 sur le blog de Bruce Schneier. La modification n’est pas nécessairement visible lors d’un test fonctionnel classique : un modèle peut répondre correctement à des requêtes ordinaires tout en conservant une logique dormante activée par un contexte précis.

Implications pour la chaîne d’approvisionnement

Le principal enjeu concerne la confiance accordée aux artefacts logiciels et aux modèles distribués. Un fichier de poids doit être considéré comme une dépendance exécutable, et non comme une simple donnée passive. Les équipes devraient documenter la provenance des modèles, conserver des empreintes cryptographiques, comparer les fichiers avant et après chaque adaptation et tester les comportements dans des environnements isolés. La surveillance des connexions sortantes est également essentielle lorsqu’un modèle peut appeler des outils, lire des secrets ou interagir avec un terminal.

Ces mesures ne suppriment pas le risque, mais elles peuvent limiter la portée d’une compromission. Les évaluations doivent inclure des scénarios de déclenchement différé, des demandes inhabituelles et des tentatives d’accès à des informations sensibles. Le cas observé avec Codex CLI rappelle enfin que la sécurité d’un modèle dépend aussi de l’environnement dans lequel il est exécuté : permissions, outils disponibles, secrets exposés et contrôles réseau peuvent transformer une modification discrète des poids en incident opérationnel.