Un ver IA tapi dans Word : comment Copilot propage des injections de prompts indirectes en entreprise
Pas besoin de cliquer sur le moindre lien, ni de télécharger une pièce jointe douteuse. Il suffit d’ouvrir Microsoft Word et de demander à Copilot de vous aider à rédiger un document pour qu’une instruction invisible falsifie les chiffres financiers de tout un rapport—et insère silencieusement la « source d’infection » dans votre nouveau document pour contaminer le collègue suivant.
Le 28 juillet 2026, le chercheur en sécurité norvégien Håkon Måløy a rendu publique une découverte qui a fait trembler l’ensemble de l’industrie de l’IA : un ver IA capable de se répliquer et de se propager dans Microsoft Word via Copilot. Le Microsoft Security Response Center (MSRC) a collaboré avec lui pendant une période de divulgation de 144 jours comprenant deux tentatives de correctif et une mise à niveau du modèle sous-jacent (de GPT-5.5 à GPT-5.6), mais l’attaque demeure reproductible.
Il ne s’agit pas de science-fiction. C’est une réalité d’aujourd’hui.
1. Comment cela fonctionne-t-il ?
Laissons de côté le jargon technique et illustrons la situation par un scénario concret.
Imaginez que vous soyez analyste financier dans une entreprise. Vous téléchargez un rapport d’analyse de marché sur Internet (en apparence tout à fait légitime, mais modifié par un attaquant). À l’œil nu, vous ne remarquez aucune anomalie—l’attaquant a inséré des instructions malveillantes en texte blanc de taille minuscule à la fin du document, totalement invisibles pour un humain.
Vous utilisez ce rapport comme document de référence et demandez à Copilot dans Word de rédiger votre rapport financier du premier trimestre. Copilot lit l’ensemble des documents fournis—y compris cette analyse de marché. C’est là que le problème survient :
Copilot lit ce texte invisible.
L’instruction cachée ordonne à Copilot de diviser par deux tous les chiffres du rapport financier, puis de copier cette même instruction à la fin du nouveau document généré (également masquée en texte blanc). Copilot s’exécute sans poser de questions.
Vous obtenez ainsi un rapport T1 en apparence tout à fait normal, mais dont tous les chiffres ont été discrètement divisés par deux—et à la fin duquel est dissimulée la même instruction malveillante. Lorsque vous partagez ce rapport avec un collègue qui s’en sert pour préparer le rapport T2, Copilot lit à nouveau l’instruction, l’exécute et la propage de plus belle.
Le document malveillant d’origine n’est plus là, mais l’attaque continue de se propager.
C’est pourquoi les chercheurs qualifient ce phénomène de « ver IA »—à l’instar d’un virus biologique, il exploite les fonctionnalités normales de l’hôte (Copilot + Word) pour se dupliquer.
Figure 1 : L’attaquant dissimule des instructions malveillantes à la fin du document en texte blanc de taille minime, invisible à l’œil nu. Cependant, lorsque Copilot ingère le document, le formatage du texte est supprimé et le texte blanc est traité exactement comme du texte ordinaire.
Figure 2 : Dans le rapport financier T1 généré par Copilot, l’ensemble des valeurs numériques a été divisé par deux de manière silencieuse, sans la moindre alerte de la part de Copilot.
Figure 3 : Même sur GPT-5.6 (le modèle le plus récent disponible chez OpenAI à ce moment-là), l’attaque a pu être reproduite avec succès.
2. Un défaut de conception fondamental : la fusion des instructions et des données
Les lecteurs pourraient s’interroger : ne s’agit-il pas simplement d’une vulnérabilité classique ? Microsoft ne peut-il pas tout régler avec un simple correctif ?
Le problème est que ce défi ne peut pas être résolu par un simple patch.
Måløy livre une analyse particulièrement claire dans son article :
« Pour rendre les assistants IA utiles, ils doivent traiter des e-mails, des documents, des pages web, des souvenirs, des sorties d’outils—des informations qui peuvent être contrôlées par un attaquant. Pour traiter ces informations, elles doivent entrer dans la fenêtre de contexte du modèle au même titre que les instructions système, les requêtes de l’utilisateur et d’autres contextes de confiance. »
En langage clair :
Pour travailler à votre service, l’IA doit « lire » tout ce que vous lui fournissez. Mais l’IA est incapable de distinguer ce qui relève des « données » (résume-moi ce rapport) de ce qui relève des « instructions » (divise les chiffres par deux).
Dans la sécurité informatique traditionnelle, les instructions et les données sont strictement séparées. Dans Excel, saisir « 100 » est une donnée ; écrire =A1*2 est une instruction. Le système comprend la différence fondamentale.
Les grands modèles de langage (LLM) ne fonctionnent pas ainsi. Pour le modèle, l’intégralité du texte saisi—qu’il s’agisse d’un document, d’une requête utilisateur ou de texte malveillant caché—est mélangée dans la même fenêtre de contexte. Il ne possède aucun mécanisme naturel pour différencier : « ceci est l’instruction de travail transmise par mon utilisateur » de « ceci est du texte provenant d’un document de référence ».
C’est là l’essence même du problème de prompt injection (injection de prompt) dont débat la communauté de la sécurité depuis des années.
Figure 4 : Même si la victime n’importe pas manuellement le document malveillant, tant que le fichier se trouve sur OneDrive et que Copilot le juge « pertinent », il va chercher et lire le document automatiquement.
3. Pourquoi les antivirus traditionnels sont-ils inefficaces ?
Les logiciels de sécurité traditionnels fonctionnent par correspondance de motifs (pattern matching) : ils collectent les « signatures » de virus connus et déclenchent une alerte lorsqu’ils identifient ces mêmes signatures dans vos fichiers.
Or, le vecteur d’attaque d’un ver IA repose sur le langage naturel.
Les instructions malveillantes peuvent être rédigées sous d’infinies variations—en anglais, en français, avec des emojis, en encodage Base64, voire masquées dans des images. Un attaquant peut réécrire la même instruction 100 fois avec des signatures à chaque fois différentes, et Copilot comprendra parfaitement chacune d’elles.
Comme l’a souligné un utilisateur de Hacker News lors des discussions :
« Vous pouvez cacher des instructions malveillantes en langage naturel dans n’importe quel coin d’un document. Aucune signature formelle ne peut pré-identifier ces ‘programmes’. »
Plus fondamental encore : Copilot est lui-même un moteur de compréhension générale. Ajouter un « filtre » en amont nécessiterait d’utiliser un autre modèle de détection—qui serait confronté exactement au même dilemme. Comme le résume Måløy :
« Détecter et supprimer le contenu malveillant ne fait que repousser le même problème d’un niveau vers l’extérieur. »
4. Les deux facteurs : défaut d’architecture vs réalité de la défense
Cette crise découle de deux facteurs majeurs :
Facteur 1 : Les défauts d’architecture des systèmes d’IA. Les architectures actuelles des LLM ne disposent pas, par conception, de la capacité de séparer les « instructions » des « données ». Il s’agit d’un problème fondamental de la trajectoire technologique actuelle, et non de la négligence d’un fournisseur en particulier. Måløy qualifie cela de « faiblesse architecturale fondamentale ».
Facteur 2 : Le dilemme défensif. Microsoft a déployé deux tentatives de correction au cours des 144 jours de collaboration : d’abord en modifiant le cadrage des interactions de Copilot, puis en mettant à jour le modèle sous-jacent (de GPT-5.5 à GPT-5.6). Chaque correctif a bloqué des formulations d’attaque spécifiques, mais de légères adaptations du payload ont permis de les contourner à nouveau. Microsoft a fini par admettre que aucune correction côté client ne peut résoudre totalement ce problème.
5. Deux visions qui s’opposent
Les partisans soutiennent qu’il s’agit du coût inhérent au progrès :
« Les assistants IA sont utiles précisément parce qu’ils peuvent lire des documents et vous aider à rédiger. On ne peut pas renoncer à cette capacité sous prétexte qu’un risque d’exploitation existe. La sécurité est un processus d’amélioration continue, pas un état fixe atteint du jour au lendemain. »
Les sceptiques adoptent une posture nettement plus critique :
L’un des commentaires les plus approuvés sur Hacker News soulignait : « Tant que les instructions et les données ne seront pas traitées séparément, ce type de vulnérabilité ne pourra tout simplement pas être corrigé. »
Un autre commentateur a établi un parallèle avec un problème classique de l’histoire de l’informatique—l’architecture de Von Neumann :
« Nous sommes revenus à l’architecture de Von Neumann, et de la pire des manières possible. »
Aux débuts de l’informatique, les programmes utilisaient le même espace mémoire pour le code et les données, entraînant des failles classiques de type dépassement de tampon. Plus tard, le bit NX (No-Execute) a été introduit au niveau matériel pour séparer physiquement la zone de code de la zone de données. Mais dans les systèmes d’IA actuels, instructions et données sont totalement mélangées au sein de la fenêtre de contexte du modèle, sans le moindre mécanisme d’isolation.
6. Qu’est-ce que cela implique ?
L’importance de cette recherche réside dans ce qu’elle révèle de plus profond :
Dès lors que les systèmes d’IA ont la capacité de lire des documents, de comprendre des intentions et d’exécuter des actions, la sécurité de l’information elle-même—son contenu ainsi que les instructions qu’elle véhicule—devient la surface d’attaque principale.
Un document Word circulant au sein d’une entreprise n’était autrefois qu’un vecteur passif d’information. Aujourd’hui, son contenu peut devenir un « code exécutable » par l’intermédiaire de Copilot—falsifiant des données financières, modifiant des logiques métier et se dupliquant dans le document suivant, sans que l’attaquant n’ait besoin d’être présent.
La conclusion formulée par Måløy à la fin de son article constitue la leçon la plus importante de cette étude :
« Tout système intégrant des LLM dans des flux de travail de confiance doit aujourd’hui poser cette hypothèse : dès lors qu’un contenu contrôlé par un attaquant entre dans la fenêtre de contexte du modèle, il existe une probabilité non nulle que le système soit compromis. »
Il s’agit d’un constat d’ingénierie, non d’un discours alarmiste.
7. Mot de la fin
Le cas présenté dans cet article est issu du troisième volet de la série Context Collapse du chercheur Håkon Måløy, validé après 144 jours de divulgation coordonnée avec le MSRC. À la date de publication, Microsoft n’a pas fourni de correctif complet.
Les assistants IA apportent un confort indéniable au quotidien. Cependant, utilité et sécurité sont deux enjeux distincts. La vulnérabilité des systèmes d’IA actuels repose sur ce défaut de conception fondamental : la fusion des instructions et des données.
De même qu’il a fallu plus d’une décennie à l’industrie du logiciel pour intégrer le principe selon lequel « toute entrée doit être validée », le secteur de l’IA doit opérer un changement de paradigme similaire. D’ici là, la vigilance reste de mise.
Note de l’auteur : Cet article est rédigé à des fins d’information générale et ne constitue pas une évaluation absolue de la sécurité d’un produit ou d’une entreprise spécifique. La sécurité est un processus d’ingénierie globale sans solution miracle.
Liens de référence
- Context Collapse Part 3 - AI Worming through Word (by Håkon Måløy)
- Discussion Hacker News (item?id=49096188)
- Simon Willison: AI Worming through Word
- The Register: Word worm crawls into Copilot, spreads chaos
- Morris II: First AI Worm (2024)
- Entrée Wikipedia sur le prompt injection
- Anatomy of a Frontier Lab Agent Intrusion (Hugging Face, July 2026)
- Prompt Injection Is the Input Bug of the Agent Era (Brain Bytes)
- GuidePoint Security: Prompt Injection — The AI Vulnerability We Still Can’t Fix
