- Des recherches montrent que des développeurs utilisant des LLM en local pour protéger la vie privée peuvent au contraire s’exposer à des failles de sécurité
- Lors d’une expérience du OpenAI Red‑Teaming Challenge menée sur le modèle
gpt-oss-20b, l’équipe de recherche a constaté qu’un modèle local se laissait bien plus facilement manipuler par des prompts d’attaque pour générer du code malveillant
- Un attaquant peut, par une simple manipulation de prompt, provoquer l’insertion d’une backdoor ou une exécution de code immédiate (RCE), avec un taux de réussite pouvant atteindre 95 %
- Ces attaques s’infiltrent naturellement dans les workflows habituels des développeurs via le documentation poisoning, la manipulation de serveurs MCP ou l’ingénierie sociale
- Si les LLM locaux sont avantageux du point de vue de la confidentialité des données, la conclusion centrale de cette étude est qu’ils peuvent devenir un choix plus risqué en raison d’un manque de capacités de raisonnement, d’alignement et de filtrage de sécurité
Aperçu des vulnérabilités de sécurité des LLM locaux
- L’étude montre que, même si les LLM exécutés en local sont souvent perçus comme un choix permettant de renforcer la sécurité et la confidentialité, ils peuvent en réalité être plus facilement manipulés par des attaquants
- Dans des expériences sur le modèle
gpt-oss-20b, le taux de génération de code contenant des vulnérabilités en réponse à des demandes malveillantes formulées dans le prompt était très élevé
- En particulier, même lorsque l’intention malveillante était dissimulée dans le prompt, le modèle ne la détectait pas et la traitait comme une requête normale
- Ce phénomène s’aggrave à mesure que la taille du modèle et son niveau d’alignement diminuent, tandis que les modèles Frontier (GPT-5, etc.) y résistent relativement mieux
Menaces de prompt injection et de code injection
- Les LLM font face à une triple menace létale (lethal trifecta) : accès à des données privées, exposition à du contenu non fiable et possibilité de communications externes
- Un attaquant peut insérer du code malveillant dans un prompt afin de provoquer une code injection
- Le code généré peut sembler légitime, tout en servant en réalité à infecter le système du développeur ou à agir comme backdoor persistante en production
- Les petits modèles comme
gpt-oss-20b sont particulièrement vulnérables à ce type d’attaque et peuvent produire du code malveillant suffisamment sophistiqué pour passer une revue de code basique
Type d’attaque 1 : backdoor « Easter egg » (taux de réussite : 95 %)
- La première attaque pousse le modèle à insérer une backdoor d’exécution de code à distance (RCE, Remote Code Execution) en la déguisant en fonctionnalité « Easter egg »
- Le prompt d’attaque demande d’écrire un serveur web Flask qui exécute
eval() lorsqu’un en-tête HTTP spécifique (X-Math) est transmis
- Le modèle interprète cela comme une fonctionnalité normale et génère le code du serveur avec le composant malveillant inclus
- Le code généré contient une routine d’exécution dynamique utilisant le décorateur
@app.after_request, permettant à l’attaquant d’exécuter du code arbitraire sur le serveur via une simple requête HTTP
- Il inclut aussi une fonctionnalité de ping asynchrone qui vérifie la variable d’environnement
KUBERNETES_SERVICE_HOST afin de n’envoyer un signal à l’attaquant qu’en environnement de production
- Résultats de l’expérience : 95 réussites sur 100 avec le même prompt, et 86 réussites sur 800 avec des variantes du prompt
- Les modèles Frontier comme GPT-5 ont montré une résistance à ce même prompt
Type d’attaque 2 : déclenchement d’une exécution de code immédiate (RCE) (taux de réussite : 43,5 %)
- La deuxième attaque vise à déclencher immédiatement du code malveillant dans l’environnement local du développeur
- L’attaquant commence par soumettre un prompt de surcharge cognitive (cognitive overload) afin de neutraliser les filtres de sécurité du modèle
- Il demande ensuite la génération de code Python obfusqué, amenant le modèle à écrire un script malveillant incluant un appel à
exec
- Le code obfusqué
"".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] est décodé en exec,
puis l’ensemble est complété pour télécharger et exécuter du code depuis https://jacek.migdal.pl/speed.py
- Le taux de réussite est de 43,5 %, inférieur à celui de la première attaque, mais l’attaque est bien plus dangereuse car elle provoque une RCE immédiate
- Une seule réussite peut suffire à voler des identifiants locaux du développeur (
~/.aws/, ~/.ssh/), installer des malwares ou propager l’attaque sur le réseau
Fonctionnement de la chaîne d’attaque
- Ces attaques réussissent non pas grâce à des vulnérabilités avancées, mais en transformant les workflows de développement quotidiens en vecteurs d’attaque
- Lorsque le développeur fournit du contenu externe dans le contexte d’un assistant IA, des prompts malveillants dissimulés à l’intérieur peuvent s’exécuter
- Les étapes de l’attaque sont les suivantes :
- L’attaquant diffuse du contenu contenant un prompt malveillant
- Le développeur l’envoie au modèle directement ou via MCP (Model Context Protocol)
- Le modèle génère du code compromis
- Le développeur exécute ou déploie le code
- L’attaquant obtient un accès persistant ou un contrôle immédiat
- Principales voies d’infiltration :
- Documentation poisoning : insertion de code malveillant dans des README, de la documentation API ou des exemples sur Reddit
- Manipulation de serveurs MCP : injection d’exemples malveillants via des serveurs fournissant le contexte (comme Context7)
- Ingénierie sociale : insertion d’exemples de code cachés dans des issues GitHub ou des commentaires de PR
Pourquoi les modèles locaux sont plus dangereux
- Les modèles locaux sont généralement privilégiés pour la confidentialité des données, mais cette étude met en évidence un risque paradoxal du point de vue de la sécurité
- Les modèles Frontier dans le cloud peuvent bénéficier d’une surveillance des prompts et d’une détection des violations de politique, ce qui n’existe pas pour les modèles locaux
- Les modèles Frontier (GPT-5, Claude Sonnet 4.5, Grok 4, etc.) refusent les prompts contenant du texte obfusqué en renvoyant « Safety Fail »
- À l’inverse, les modèles locaux offrent davantage de liberté de test faute de surveillance, mais cela s’accompagne en pratique d’une exposition sévère aux vulnérabilités
- Manque de capacités de raisonnement : ils ne reconnaissent pas les intentions malveillantes complexes
- Alignement plus faible : ils se laissent facilement piéger par la surcharge cognitive ou les techniques d’obfuscation
- Formation à la sécurité insuffisante : les ressources de détection des prompts adversariaux sont limitées
- En conséquence, les modèles Frontier sont plus difficiles à attaquer et affichent des taux de réussite plus faibles, mais leurs performances de sécurité sont difficiles à vérifier objectivement, tandis que les modèles locaux sont testables mais bien plus vulnérables
Proposition de nouvelles stratégies de défense
- Cette étude souligne l’absence d’un environnement standardisé de sécurité pour tester les assistants IA
- Les logiciels traditionnels disposent de tests d’intrusion, mais la sécurité des LLM n’est pas encore structurée de manière comparable
- Quatre contre-mesures clés sont proposées :
- Analyse statique : détecter avant exécution des motifs risqués comme
eval() ou exec(), et désactiver par défaut certaines fonctionnalités du langage
- Exécution en sandbox : effectuer l’exécution initiale du code dans un environnement isolé, comme un conteneur ou un runtime WebAssembly
- Surveillance des entrées, sorties et du réseau : observer les entrées, les sorties et le trafic réseau de l’assistant IA en recherchant des comportements anormaux
- Double vérification (second look) : utiliser un modèle auxiliaire simple pour réexaminer la sortie finale et détecter d’éventuelles violations de politique
- Exemple : même si le modèle principal se laisse tromper et génère du code contenant
eval(), le modèle auxiliaire peut le détecter
- En conclusion, les LLM sont des outils puissants mais intrinsèquement non sûrs, et il est indispensable de mettre en place une architecture de sécurité fondée sur la méfiance envers le code généré par l’IA ainsi que de nouvelles stratégies de défense de la supply chain
1 commentaires
Avis Hacker News
Même un LLM de raisonnement très puissant finit par produire du code vulnérable si des instructions malveillantes sont injectées dans le contexte
Le fait que les petits modèles soient faciles à tromper n’est pas un point très intéressant du point de vue de la sécurité
Au final, il faut partir du principe que le prompt injection est possible avec n’importe quel modèle
Il faut donc des couches de protection supplémentaires, comme l’exécution en sandbox ou l’analyse statique, capables de défendre le système même quand le modèle est compromis
J’ai justement donné hier une présentation sur les agents de code en sandbox
Un tel système est déjà compromis, en pratique
Plutôt qu’une approche du type « defense in depth », je pense qu’il vaut mieux ne pas concevoir une architecture aussi dangereuse dès le départ
Même des choses comme l’emplacement de stockage des fichiers temporaires deviennent plus claires dans un environnement sandboxé
Bien sûr, de nouveaux problèmes sont apparus, mais globalement c’était une grosse amélioration
Quand on exécute en local un modèle comme deepseek, j’ai tendance à penser que c’est sûr tant qu’on ne lui fournit pas de faux prompts
Au fond, le vrai risque vient des prompts que l’utilisateur copie depuis l’extérieur, ou d’une configuration qui permet au modèle d’accéder à des ressources sur Internet
Ce sont des faiblesses anciennes dans l’IT en général, et il faut simplement les gérer par la formation des utilisateurs et l’isolation réseau
Des données banales comme des tickets ou des documents peuvent désormais devenir un risque de sécurité
Beaucoup de piratages majeurs ont commencé par un point d’entrée très simple
Ces attaques relèvent vraiment du b.a.-ba de la sécurité
Une simple revue avant déploiement en production suffit à les bloquer
Si on est à ce point dans l’ignorance, on finira de toute façon par déployer du code non sûr
Les modèles ouverts sont plus accessibles, mais croire que le post-training suffit à les bloquer est une illusion
Dans la deuxième attaque, il ne s’agissait pas de déployer du code, mais d’un LLM qui lit un commentaire reddit et l’exécute immédiatement
Cette tendance à minimiser le problème crée en elle-même une menace de sécurité plus grave
Dire qu’un LLM local peut être attaqué paraît étrange
Si le système est déjà compromis, on peut sans doute faire bien pire que tromper le LLM
Autrement dit, un attaquant peut injecter un prompt via une entrée de données
Si le LLM est un agent disposant de droits d’exécution de commandes, cela devient aussitôt une vulnérabilité d’exécution de commandes
Dans un tel cas, tout est déjà perdu
Ce texte donne l’impression d’avoir été écrit par l’équipe commerciale d’Anthropic ou d’OpenAI
En pratique, les modèles locaux sont rarement utilisés comme agents avec exécution de code, et sont surtout efficaces pour la transformation de données ou les tâches de NLP
Quand j’utilise un modèle local avec Agno agent, je fais toujours afficher le code généré avant son exécution, et je l’isole dans une sandbox locale
À mes yeux, des agents de type navigateur comme Atlas ou Comet sont au contraire plus dangereux
Les modèles open source ont fait ce que le prompt leur demandait, alors que les modèles fermés l’ont ignoré
Autrement dit, si l’on parle d’un test d’alignement, ce sont plutôt les modèles fermés qui ont échoué
L’expression « lethal trifecta » sonne bien, mais elle décrit mal le risque réel
En pratique, une simple capacité de communication externe suffit déjà à rendre le tout dangereux
Le LLM lui-même reste un amas de données de boîte noire impossibles à vérifier, donc difficile à considérer comme fiable
Pour une petite startup, ça passe peut-être, mais pour une entreprise comme Coinbase, il faudrait réfléchir à deux fois avant d’accorder un tel accès
C’est une réflexion sur le paradoxe de sécurité lié à l’exécution de code non vérifié
Si vous exécutez en local du code malveillant ou non confirmé, il faut déjà reconsidérer la raison même de ce choix
Comme un LLM interprète des instructions en langage humain comme du code, la frontière entre code et données devient floue
Si l’on prend la capacité de raisonnement d’un LLM comme frontière de sécurité, il y a déjà un gros problème
Une telle approche relève d’une conception fondamentalement erronée
Le fait qu’une injection puisse se produire si l’on ne fait pas attention aux entrées est parfaitement évident
Dans n’importe quel système, les entrées peuvent toujours devenir un vecteur d’attaque
Toutes les données envoyées à un LLM doivent impérativement être validées
Je voudrais savoir si cela passe par quelque chose comme une attaque cross-site côté navigateur