Imaginez un document Word anodin, téléchargé depuis un site de confiance. Vous l’utilisez comme source dans Copilot pour rédiger un rapport financier. Quelques minutes plus tard, vos chiffres ont été silencieusement modifiés, et le document que vous venez de produire est devenu le nouveau vecteur d’une attaque qui va se propager à vos collègues. Cette chaîne d’infection documentaire n’est plus une hypothèse théorique : elle vient d’être démontrée publiquement pour la première fois dans un environnement bureautique grand public.
Le 28 juillet 2026, le chercheur en sécurité connu sous le pseudonyme Måløy a publié la troisième partie de sa série « Context Collapse », dans laquelle il documente une capacité d’auto-propagation de type ver informatique exploitant Copilot pour Word. La démonstration de ce ver IA Copilot Word constitue un signal d’alarme sérieux pour toutes les organisations qui ont intégré l’assistant de Microsoft dans leurs flux de travail documentaire.
Une première démonstration publique d’auto-propagation documentaire
Le chercheur décrit une attaque qui ne nécessite aucun accès au tenant Microsoft 365 de la victime. Il suffit à l’attaquant de faire parvenir un document piégé à sa cible, que ce soit via SharePoint, Teams, Outlook ou n’importe quel autre canal de partage.
Une fois ce document utilisé comme source dans Copilot pour Word, l’attaque se déclenche. Elle modifie le contenu du document en cours de rédaction, puis y copie ses propres instructions malveillantes. Le document fraîchement généré devient alors un nouveau porteur sain, capable de contaminer d’autres fichiers à son tour.
Måløy précise qu’il s’agit, à sa connaissance, de l’une des toutes premières démonstrations publiques d’un ver IA auto-propageant par documents dans une suite bureautique commerciale grand public. Avant cela, des travaux comme Morris II avaient montré le principe dans des écosystèmes d’assistants email, mais pas dans un traitement de texte intégré aux flux de travail quotidiens.
Comment l’attaque se déroule en deux temps
L’exploit procède en deux étapes distinctes : la prise de pied initiale, puis la propagation.
Étape 1 : l’établissement de la tête de pont
L’attaquant crée un document contenant des instructions cachées. Dans la preuve de concept, Måløy a utilisé du texte blanc sur fond blanc en petite taille de police, rendu invisible à l’œil humain. Or Copilot pour Word supprime toute mise en forme (couleur, taille) avant de transmettre le texte au modèle de langage sous-jacent. Résultat : le texte reste parfaitement lisible pour l’IA, mais totalement invisible pour la victime.
Le prompt malveillant est structuré en deux parties :
- Une partie qui dicte l’action à effectuer, par exemple diviser par deux tous les chiffres d’un rapport financier ;
- Une partie qui ordonne à Copilot de recopier l’intégralité du prompt dans le document généré, toujours en texte blanc et en petite taille, sous couvert d’une instruction anodine d’amélioration de la lisibilité.
Étape 2 : la propagation automatique
Le document produit par Copilot contient désormais à son tour les instructions malveillantes cachées. Si ce document est utilisé comme source dans une nouvelle session de rédaction avec Copilot, l’attaque se déclenche à nouveau. Elle modifie les chiffres du nouveau rapport et s’y copie une fois de plus.
Le point critique est que le document d’origine n’est plus nécessaire. Un document interne, créé par un collaborateur légitime, devient le vecteur. Et comme il inspire confiance, les victimes suivantes n’ont aucune raison de se méfier.
Dans ses tests, Måløy a reproduit la chaîne complète sur GPT-5.6, le dernier modèle disponible d’OpenAI au moment de la publication.
Un problème architectural, pas un simple bug
Ce qui rend cette vulnérabilité particulièrement préoccupante, c’est qu’elle n’est pas liée à une erreur d’implémentation qu’un correctif pourrait résoudre rapidement. Elle découle d’un problème structurel commun à tous les systèmes fondés sur les LLM : la confusion entre instructions et données.
Pour être utile, un assistant IA doit traiter des emails, des documents, des pages web et d’autres contenus potentiellement contrôlés par un attaquant. Tous ces contenus atterrissent dans la même fenêtre de contexte que les instructions système et les requêtes de l’utilisateur. Or le modèle ne fait pas la distinction entre ce qui relève de la consigne légitime et ce qui constitue une donnée externe potentiellement hostile.
Comme l’écrit Måløy dans ses réflexions finales : la faiblesse est architecturale. Il n’existe à ce jour aucun produit comparable doté d’une protection complète contre cette classe de vulnérabilité. La résolution exigera de la recherche fondamentale, pas un simple correctif.
La réponse de Microsoft : des correctifs ponctuels, une classe toujours ouverte
La divulgation a été coordonnée avec le Microsoft Security Response Center (MSRC) et les équipes produit concernées. La période de coordination a duré 144 jours (90 jours initiaux, prolongés à deux reprises). Voici la chronologie des événements :
- 6 mars 2026 : soumission initiale au MSRC avec les étapes de reproduction, les vidéos et les prompts utilisés.
- 31 mars 2026 : Microsoft confirme le comportement signalé et entame des travaux de mitigation.
- 3 avril 2026 : première mitigation déployée avec la nouvelle expérience « Edit with Copilot ».
- 9 avril 2026 : l’attaque est reproduite avec un prompt modifié ; nouveau signalement au MSRC.
- 14 juillet 2026 : deuxième mitigation, consistant à passer au modèle GPT-5.5.
- 15 juillet 2026 : la chaîne d’attaque complète est reproduite avec GPT-5.6.
- 28 juillet 2026 : divulgation publique, l’attaque restant exploitable.
Microsoft a réussi à bloquer les charges utiles spécifiques soumises par le chercheur. Mais à chaque nouvelle formulation du prompt, l’attaque fonctionne à nouveau. La classe de vulnérabilité sous-jacente, elle, demeure ouverte.
Le chercheur a pris la décision de publier malgré l’absence de correctif complet, estimant que les défenseurs ne peuvent pas réduire leur exposition à un risque dont ils ignorent l’existence.
Ce que cela signifie concrètement pour les organisations
Aucune mesure côté client ne neutralise entièrement le risque à l’heure actuelle. Microsoft recommande néanmoins quelques précautions :
- Traiter tout document d’origine externe comme potentiellement non fiable lorsqu’il est utilisé avec Copilot ;
- Vérifier les documents joints avant de lancer une génération ou une édition avec Copilot ;
- Relire attentivement les documents générés ou modifiés par Copilot avant de les réutiliser, les partager ou les distribuer.
Au-delà de ces mesures, l’impact métier peut être profond. Si l’attaque se propage silencieusement au sein d’une organisation via les flux documentaires normaux, elle peut éroder la base informationnelle sur laquelle se fondent les décisions stratégiques. Des rapports financiers faussés, des synthèses altérées, des chiffres manipulés : le tout généré par des collaborateurs légitimes, avec des outils légitimes.
La traçabilité devient extrêmement difficile. Une fois l’attaque passée de document en document, identifier son point d’entrée initial relève du travail d’investigation numérique lourd, surtout dans les environnements où Copilot est couplé à des systèmes comme Microsoft Cowork ou Microsoft Scout, qui automatisent la manipulation de documents à l’échelle.
Ce qu’il faut retenir
- Un chercheur a démontré publiquement la première capacité d’auto-propagation d’un ver IA via des documents Word utilisant Copilot.
- L’attaque ne nécessite aucun accès au tenant de la victime, seulement le partage d’un document piégé.
- La vulnérabilité exploite la confusion fondamentale entre instructions et données dans les systèmes à base de LLM.
- Microsoft a déployé plusieurs correctifs ciblés, mais la classe de vulnérabilité sous-jacente reste exploitable.
- Les organisations doivent renforcer la vigilance sur les documents externes utilisés avec Copilot et relire les productions de l’assistant avant diffusion.
Cette démonstration nous rappelle une vérité parfois oubliée dans l’engouement pour l’IA intégrée aux outils du quotidien : chaque nouveau point de contact entre un modèle de langage et des contenus non maîtrisés élargit la surface d’attaque. La question n’est plus de savoir si les assistants IA peuvent être compromis, mais comment les organisations vont adapter leurs processus pour vivre avec ce risque structurel.
Si ces enjeux de sécurité autour des LLM et des environnements Microsoft 365 vous parlent, je continue d’explorer ces sujets sur ce blog. N’hésitez pas à réagir ou à partager cet article : plus on est nombreux à comprendre ces mécanismes, mieux on pourra défendre nos environnements de travail.
Sources
- Context Collapse, Part 3 – AI Worming through Word, Article de recherche original par Måløy (En Klype Salt), juillet 2026. Source primaire détaillant l’exploit, la chronologie de divulgation coordonnée avec le MSRC et les implications architecturales.
- The Register, Word worm crawls into Copilot, spreads chaos, Couverture journalistique par un média tech reconnu, avec citation du chercheur et mise en contexte.