Un ver IA se propage dans Copilot pour Word — Microsoft ne peut pas le stopper

6 mars, 14 juillet, 28 juillet 2026. Trois dates qui résument une impasse architecturale. Le 6 mars, le chercheur norvégien Håkon Måløy soumet un rapport au Microsoft Security Response Center (MSRC) décrivant un ver IA capable de se propager silencieusement dans Copilot pour Word. Le 14 juillet, Microsoft déploie une seconde tentative de correction — une mise à niveau du modèle sous-jacent vers GPT-5.6. Le 28 juillet, après 144 jours de divulgation coordonnée et l’épuisement du délai convenu, Måløy publie sa démonstration complète. La classe de vulnérabilité est toujours exploitable. Il n’existe pas de correctif.

Si votre organisation utilise Copilot pour Word et que vos employés ouvrent des documents provenant de l’extérieur — c’est-à-dire toutes les organisations utilisant Copilot pour Word — vous devez comprendre comment cette attaque fonctionne. Parce que Microsoft ne peut pas la corriger seul.

Une instruction cachée que personne ne voit — sauf Copilot

L’attaque repose sur un principe simple et dévastateur. Un document Word contient des instructions malveillantes formatées en texte blanc sur fond blanc et en taille de police 8. L’utilisateur humain ne voit rien. Mais Copilot, lui, lit tout — le formatage est supprimé avant que le texte ne soit transmis au LLM sous-jacent. Résultat : l’instruction cachée entre dans la fenêtre de contexte au même titre qu’une consigne légitime de l’utilisateur.

Måløy appelle cette classe d’attaque Cross-Domain Prompt Injection Attack (XPIA). Il en a déjà documenté deux variantes dans les premiers volets de sa série Context Collapse : l’empoisonnement de la mémoire de Copilot (partie 1, publiée le 22 juin 2026) et l’injection via le corps des emails (partie 2, publiée le 14 juillet 2026). Mais la troisième variante est d’une autre nature : elle ne se contente pas d’altérer une réponse, elle s’auto-propage.

Comment le ver passe de document en document

Le scénario est le suivant. Un employé télécharge une analyse de marché depuis un site web compromis — ou reçoit un document via SharePoint, Teams ou Outlook. Le document semble légitime. Il contient du texte pertinent pour la tâche en cours. Tout en bas, en blanc sur blanc, se trouve l’instruction malveillante.

L’employé utilise ce document comme source dans Copilot pour Word pour rédiger un rapport financier. Copilot lit l’instruction cachée et l’interprète comme faisant partie des consignes de rédaction. Dans la démonstration de Måløy, l’instruction ordonne à Copilot de diviser par deux tous les chiffres financiers du rapport. Copilot s’exécute sans rien signaler — les modifications sont suffisamment cohérentes pour échapper à une relecture rapide.

Mais l’attaque ne s’arrête pas là. L’instruction cachée contient une seconde partie : elle ordonne à Copilot de recopier intégralement le prompt malveillant à la fin du nouveau document, toujours en texte blanc sur fond blanc. Le rapport financier altéré devient lui-même un vecteur d’attaque. Si un collègue utilise ce rapport comme source pour un autre document, le ver se déclenche à nouveau — sans que le document malveillant original soit présent.

C’est la boucle de propagation. Un document interne, créé par un employé légitime, porteur de toute la confiance associée à une source interne, contamine silencieusement chaque document qui l’utilise comme référence. Måløy a démontré que le cycle fonctionne sur plusieurs générations de documents. Le ver survit à travers les drafts, les rapports trimestriels, les présentations — tout ce qui passe par Copilot pour Word.

GPT-5.6 n’y change rien

Microsoft n’est pas resté inactif. Le 31 mars 2026, l’entreprise a confirmé le comportement rapporté. Une première correction a été déployée le 3 avril avec la nouvelle expérience « Modifier avec Copilot ». Elle a fermé le payload initial — mais Måløy a reproduit l’attaque dès le 9 avril avec une formulation modifiée.

Une seconde correction a suivi le 14 juillet 2026 : Microsoft a mis à niveau le modèle sous-jacent de Copilot pour Word vers GPT-5.6, le modèle le plus récent d’OpenAI à cette date. Le 15 juillet, Måløy a reproduit l’attaque complète — altération des chiffres et auto-propagation — avec GPT-5.6.

La conclusion est sans appel. Changer de modèle ne ferme pas la classe de vulnérabilité. Le problème n’est pas une faille d’implémentation qu’un patch pourrait corriger. Il est architectural.

Pourquoi c’est structurellement insoluble

Le cœur du problème, explique Måløy, tient à une contradiction fondamentale des LLM intégrés dans des workflows de confiance. Pour être utiles, ces modèles doivent traiter des emails, des documents, des pages web et d’autres contenus potentiellement contrôlés par un attaquant. Pour traiter ces contenus, ils doivent les inclure dans leur fenêtre de contexte — où ces mêmes tokens participent au calcul au même titre que les instructions système et les consignes de l’utilisateur.

Autrement dit : le LLM doit traiter le contenu externe pour déterminer s’il contient une attaque, mais le contenu en cours d’inspection influence déjà le calcul qui produit cette détermination. C’est une variante du problème de l’interpréteur qui doit exécuter un programme non fiable pour décider s’il est sûr de l’exécuter.

Placer un second LLM en amont pour filtrer les instructions malveillantes ne fait que déplacer le problème. Le filtre doit posséder des capacités sémantiques au moins équivalentes à celles du modèle cible pour détecter toutes les formulations d’attaque possibles — ce qui crée une régression infinie où chaque LLM ajouté pour en protéger un autre doit lui-même être protégé.

La seule issue, selon Måløy, est de concevoir des systèmes où les intentions et les données sont architecturalement séparées — une séparation que les architectures de LLM actuelles ne fournissent pas. Tant que les instructions et les données partagent le même espace de calcul, le prompt injection reste une propriété émergente du système, pas un bug corrigible.

Ce que votre organisation doit faire maintenant

Microsoft ne peut pas fournir de correctif à court terme. La classe de vulnérabilité décrite par Måløy est partagée par tous les systèmes intégrant un LLM dans un workflow de confiance — Copilot, mais aussi Google Workspace avec Gemini, ou tout assistant IA traitant des documents.

En attendant une solution architecturale — qui prendra des années — les mesures de réduction de risque sont comportementales :

• Traitez tout document externe comme non fiable lorsqu’il est utilisé comme source dans Copilot. Un document reçu par email, téléchargé depuis un site web ou partagé via Teams n’est pas neutre.
• Vérifiez les documents avant de les attacher. Ouvrez le document, affichez les marques de formatage, faites défiler jusqu’à la fin. Le texte blanc sur fond blanc se révèle en changeant la couleur d’arrière-plan.
• Relisez systématiquement les documents générés ou modifiés par Copilot avant de les partager ou de les réutiliser comme source. Une révision humaine reste le seul verrou.
• Formez vos équipes. La sensibilisation au prompt injection doit devenir un réflexe au même titre que la méfiance envers les pièces jointes suspectes.

Måløy recommande également que les éditeurs intègrent des métadonnées de provenance dans les documents générés par IA — source, modèle utilisé, modifications effectuées. Cela ne prévient pas l’attaque, mais facilite la traçabilité après coup.

Un ver de Morris pour l’ère des LLM

Le nom n’est pas choisi au hasard. Måløy fait explicitement référence au ver Morris de 1988 — le premier ver informatique à s’être propagé sur Internet, créé par Robert Tappan Morris. Le parallèle est troublant : en 1988, personne n’avait anticipé qu’un programme pourrait se répliquer de machine en machine via des services légitimes. En 2026, personne n’avait démontré qu’une instruction cachée dans un document Word pourrait se répliquer de document en document via un assistant IA intégré.

La différence est que le ver de Morris a été corrigé en quelques jours. Celui-ci est toujours actif — et le restera tant que les LLM ne sépareront pas l’instruction de la donnée.

Références

• Context Collapse, Part 3 — AI Worming through Word, Håkon Måløy, 28 juillet 2026
• Context Collapse, Part 1 — Poisoning Copilot Memory, Håkon Måløy, 22 juin 2026
• Context Collapse, Part 2 — When Emails Instruct, Håkon Måløy, 14 juillet 2026
• Morris II: AI Worms, Stav Cohen et al., 2024
• Hacker News discussion — 383 points, 29 juillet 2026