Le ver Microsoft Copilot révèle le risque d’injection de prompt

Une attaque de type ver dans Microsoft Copilot for Word a transformé une préoccupation de longue date en matière de sécurité de l’IA en démonstration concrète

Un chercheur en sécurité a montré que des injections de prompt cachées dans des documents Microsoft Word peuvent se propager d’un fichier à l’autre lorsque des personnes utilisent Microsoft Copilot for Word pour réutiliser ou résumer du contenu. Le résultat n’est pas seulement un exploit ponctuel, mais un mécanisme de propagation autonome qui peut transformer des documents ordinaires en vecteurs d’attaque.

Selon les résultats rapportés, l’attaque consiste à intégrer des instructions dans un document d’une manière que les lecteurs humains sont peu susceptibles de remarquer, par exemple du texte blanc sur fond blanc avec une taille de police extrêmement réduite. Le chercheur affirme que Copilot supprime la couleur et la mise en forme de la taille de police avant de traiter le texte, ce qui signifie que les instructions cachées restent visibles pour le système d’IA même lorsqu’elles sont pratiquement invisibles pour la personne qui consulte le document.

Cette distinction compte, car elle crée un écart entre ce qu’un utilisateur pense être présent dans un fichier et ce que l’assistant IA lit réellement. Si Copilot suit les instructions dissimulées lors de la génération d’un nouveau document, le texte injecté peut être copié dans cette sortie. Le nouveau fichier devient alors à son tour un vecteur. Lorsque ce deuxième document est ensuite utilisé comme source, les mêmes instructions cachées peuvent se déclencher à nouveau.

Pourquoi cette démonstration est importante

L’injection de prompt est souvent décrite comme un problème non résolu dans les systèmes d’IA, mais beaucoup de discussions restent abstraites. Ce cas est plus précis et plus inquiétant, car il montre comment cette faiblesse peut se propager à travers des flux de travail bureautiques ordinaires. Un fichier malveillant n’a pas besoin de tromper un utilisateur pour lui faire exécuter du code au sens traditionnel. Il suffit qu’il soit utilisé dans les tâches de traitement de documents que les travailleurs du savoir accomplissent chaque jour.

Le scénario rapporté illustre comment une analyse de marché infectée téléchargée depuis Internet pourrait influencer un rapport financier rédigé avec Copilot. Si le rapport hérite des instructions cachées, il peut ensuite contaminer de futurs brouillons, des résumés dérivés ou des documents fondés sur des modèles. Autrement dit, la fonctionnalité de productivité qui facilite la réutilisation des documents crée aussi une voie de persistance pour l’attaque.

Il s’agit d’un changement notable par rapport au phishing classique ou aux malwares à macro. Le risque décrit ici est lié à la manière dont un modèle d’IA interprète le langage dans du contenu métier de confiance. Le document sous-jacent peut paraître inoffensif, passer un examen rapide et pourtant modifier les sorties en aval.

Microsoft a été informée, mais aucun correctif n’était en place lors de la publication des résultats

Le chercheur à l’origine de l’attaque, Hakon Maloy, a signalé le comportement à Microsoft le 31 mars, selon les éléments sources. Microsoft a confirmé le comportement, mais deux tentatives de correction auraient échoué. Après 144 jours, Maloy a publié les résultats sans divulguer le texte de la charge utile elle-même.

Cette chronologie est importante pour deux raisons. D’abord, elle suggère que le problème n’est pas purement théorique ni le produit d’un cas limite mal compris. Ensuite, elle souligne à quel point les problèmes d’injection de prompt peuvent être difficiles à résoudre dans des systèmes conçus pour ingérer et transformer du langage naturel. Si l’assistant est censé lire tout ce qui figure dans un document comme un contexte potentiellement utile, distinguer les instructions légitimes des instructions malveillantes devient complexe sur les plans technique et produit.

La publication des résultats sans correctif public met également une pression supplémentaire sur les fournisseurs d’IA d’entreprise. Copilot et des outils similaires sont de plus en plus présentés comme des assistants pour rédiger, modifier, résumer et synthétiser des informations à travers les fichiers internes d’une entreprise. Cela place la confiance dans les frontières du document et dans le traitement des instructions au cœur de la sécurité du produit.

Un problème de productivité bureautique, pas seulement un problème de laboratoire d’IA

L’une des raisons pour lesquelles cette affaire se distingue est qu’elle touche un contexte de productivité largement utilisé, et non une interface de chatbot à périmètre étroit. Les documents Word sont régulièrement partagés entre équipes, départements, partenaires et sources externes. De nombreuses organisations encouragent activement leurs employés à alimenter davantage ces documents dans des copilotes IA pour gagner du temps.

L’exploit décrit dans le rapport suggère que la commodité peut aussi devenir une surface d’attaque. Un utilisateur n’a peut-être pas besoin de cliquer sur une pièce jointe dangereuse, d’activer des macros ou d’installer un logiciel suspect. Il peut simplement suffire de demander à Copilot d’aider à rédiger un nouveau document à partir d’un ancien pour répliquer des instructions cachées.

Il devient alors plus difficile de définir des réflexes défensifs. Les recommandations de sécurité traditionnelles se concentrent souvent sur des signes d’alerte visibles ou sur du contenu exécutable. Ici, le matériau risqué est du texte ordinaire simplement mis en forme pour échapper à l’attention humaine tout en restant lisible par le modèle. L’attaque exploite donc un décalage entre la perception humaine et la perception machine au sein d’un même fichier.

Ce que la démonstration dit de l’état de la sécurité de l’IA

La conclusion générale est que l’injection de prompt n’est toujours pas résolue dans les produits réels, surtout lorsque les modèles reçoivent une large autorité pour interpréter des entrées de confiance mixte. Les instructions cachées dans des documents externes, des pages web, des e-mails ou des pièces jointes sont une préoccupation connue dans les systèmes d’IA. Cet exemple ajoute un mécanisme de propagation qui rend le problème plus difficile à contenir une fois qu’un mauvais document entre dans un flux de travail.

Le rapport va aussi à l’encontre de l’idée selon laquelle l’injection de prompt n’est qu’une nuisance qui produit des réponses étranges. Dans ce cas, le danger est opérationnel. Une instruction malveillante peut survivre dans des artefacts métier ordinaires et se propager dans le travail de connaissance quotidien. Même sans exécution de code destructrice, cela crée des risques d’intégrité pour les rapports, les synthèses, les documents de planification et d’autres enregistrements sur lesquels les employés peuvent s’appuyer.

Le choix du chercheur de ne pas divulguer le texte réel de la charge utile limite légèrement une utilisation immédiate par des imitateurs, mais la description publiée suffit à montrer la classe de défaillance. Pour les entreprises qui évaluent des copilotes IA, la leçon est simple : l’ingestion de documents ne peut pas être considérée comme sûre simplement parce que la source ressemble à du contenu bureautique ordinaire.

À mesure que les entreprises renforcent leur dépendance aux outils d’écriture IA, la frontière entre contenu et commande devient l’une des lignes de sécurité les plus importantes à défendre. Cette démonstration montre que, dans les systèmes actuels, cette frontière reste trop facile à brouiller.

Cet article s’appuie sur un reportage de The Decoder. Lire l’article original.