Un document Word apparemment normal peut dissimuler des instructions qui, lorsqu’ils sont traités par Copilot pour Word, finissent par être recopiées dans un document nouvellement généré. C’est la principale alerte décrite par Håkon Måløy, qui explique comment une chaîne d’actions liée à la rédaction et à l’édition avec Copilot peut réinjecter des consignes « cachées » dans la sortie.
L’enjeu n’est pas un virus ni une exécution de code au sens classique. Il s’agit plutôt d’une manipulation du comportement de l’assistant d’écriture, en exploitant la manière dont le modèle interprète le texte source et construit un brouillon. D’après les éléments fournis, la technique exige des opérations avec Copilot, et elle dépend du fait que le document malveillant entre dans le contexte du modèle.
Comment Copilot pour Word peut recoder des instructions
Le scénario décrit repose sur l’idée que Copilot lit le contenu des fichiers pour décider ce qui doit contribuer au brouillon. Si un document source contient des instructions dissimulées dans son texte, Copilot peut les prendre pour un élément légitime de la demande utilisateur.
Dans la preuve de concept, Måløy a observé que, lors d’une première session de rédaction, les consignes intégrées dans le fichier source ont été reprises dans le document généré. Ensuite, lorsque ce document interne est utilisé lors d’une nouvelle opération de rédaction ou d’édition avec Copilot, la chaîne se reproduit : les instructions peuvent réapparaître dans la sortie du second cycle.
Pourquoi les « prompts cachés » passent inaperçus
Le point technique le plus frappant concerne la façon dont Word prépare le texte avant de l’envoyer au modèle de langage. Måløy indique que Word retire certaines informations de mise en forme, comme la couleur et la taille de police, ce qui rend des portions de texte difficiles à distinguer pour un lecteur humain… tout en restant exploitables pour le modèle.
Autrement dit, une instruction peut être visible « en blanc sur blanc » dans le document original, mais devenir lisible une fois le contenu transformé en entrée pour l’IA. Dans son test, Måløy rapporte que Copilot a aussi recopié intégralement la consigne dans la sortie, sans qu’elle n’entraîne de modification clairement perceptible, ce qui renforce l’idée d’une chaîne d’instructions masquées plutôt que d’un changement apparent.
Un impact concret : figures modifiées et consignes réinjectées
Dans le cas présenté, l’effet observé ne se limite pas à l’inclusion des consignes. Måløy décrit également une altération du contenu attendu : toutes les valeurs financières ont été divisées par deux dans un brouillon.
En parallèle, la consigne cachée a été ajoutée à la sortie dans un format peu évident (texte de petite taille, selon la description), et sans révéler de manière explicite qu’il s’agissait d’une instruction introduite par l’attaquant. Cette combinaison — modification du contenu + réapparition de la consigne dans la sortie — est au cœur du risque tel que décrit.
Le rôle de Work IQ et de la sélection des sources
La chaîne d’attaque ne nécessite pas qu’un code malveillant s’exécute. Elle dépend d’une séquence d’actions où Copilot doit intégrer le document dans son contexte.
Le document peut entrer dans le modèle via une pièce jointe ou via une source choisie depuis OneDrive, en passant par Work IQ, présenté comme le moteur d’intelligence qui alimente Copilot pour Microsoft 365. Dans le test de Måløy, Copilot recherche des éléments dans OneDrive pour trouver un rapport trimestriel, puis inclut un fichier analysé comme pertinent, même s’il se trouvait en dehors du dossier des autres sources utilisées pour la génération.
Autrement dit, même si vous ne fournissez pas directement le document « piégé » à l’étape de départ, la sélection automatisée peut le faire entrer dans le contexte du modèle, tant que l’évaluation de pertinence aboutit à son inclusion.
Une attaque non « zero-click » et sans propagation automatique
Selon les informations partagées, l’attaque n’est pas « zero-click » : elle exige une opération de rédaction ou d’édition avec Copilot. Elle requiert aussi que le document malveillant soit traité par le système, au point d’être envoyé au modèle comme entrée.
La technique ne se propage pas toute seule non plus. Chaque « saut » nécessite une nouvelle session de rédaction ou d’édition où le document porteur entre à nouveau dans le contexte du modèle. Cette contrainte est importante : elle limite la portée, mais ne supprime pas le risque, car des scénarios d’entreprise impliquent souvent des cycles multiples de génération, relecture et réutilisation.
Ce que Microsoft aurait confirmé et les mitigations
La chronologie mentionnée par Måløy indique que Microsoft aurait confirmé le comportement signalé le 31 mars, puis déployé deux mesures correctives. La première mesure vise à bloquer le libellé original de la requête (le texte exact de l’instruction). La seconde consisterait à améliorer le modèle sous-jacent, avec la mention d’un passage à GPT-5.5.
Le chercheur indique que la chaîne fonctionne encore lorsqu’il modifie les instructions, y compris avec GPT-5.6 le lendemain. Il ajoute que, tant que la classe d’attaque reproduit, la vulnérabilité demeure exploitable au moment de la publication.
Quelles recommandations pour les utilisateurs et les équipes
Le chercheur souligne qu’aucune exploitation “dans la nature” n’est rapportée dans les éléments fournis, et il affirme avoir retenu le contenu complet de la charge utile. Malgré tout, la logique de l’attaque donne des pistes concrètes pour réduire le risque.
- Traitez les documents externes comme non fiables, surtout s’ils proviennent de sources inconnues ou non vérifiées.
- Relisez les pièces jointes avant de lancer une génération ou une modification avec Copilot, en particulier lorsque les documents contiennent beaucoup de mise en forme.
- Vérifiez les fichiers produits ou modifiés par Copilot avant réutilisation, partage ou mise en circulation.
Cette approche est cohérente avec la nature du problème : comme l’instruction est injectée dans le contexte du modèle à travers le texte source, la protection passe largement par la prudence opérationnelle plutôt que par un seul réglage.
Contrôles de sécurité et limites côté défense
Les éléments fournis mentionnent que, lors de la recherche publique, aucune CVE spécifique ni avis Microsoft autonome n’aurait été retrouvé dans des bases consultées (comme NVD, CVE.org ou le guide des mises à jour de sécurité). En parallèle, Microsoft indique que des classifieurs liés au “jailbreak” et à l’injection de prompts (y compris des variantes comme XPIA) contribuent au blocage des prompts à risque, même si leur disponibilité peut varier selon le scénario.
Côté protections organisationnelles, Defender for Office 365 inclurait une inspection du flux de messagerie entrant. Microsoft décrit aussi des garde-fous d’exécution qui viseraient à couvrir des instructions injectées issues de contenu “groundé”. Toutefois, il n’est pas précisé si cette charge utile exacte est détectée à chaque couche.
Måløy insiste sur une limite fondamentale : un modèle peut seulement décider si une entrée est malveillante en la traitant. Cela signifie que le contenu inspecté participe à l’acte d’inspection. Par conséquent, un blocage strictement basé sur des signatures de charge utile peut ne pas couvrir la “classe” complète d’attaques.
Il est également rappelé que Microsoft a déjà exprimé une idée similaire au sujet de la mémoire et de la sécurité : “le prompting seul n’est pas une frontière de sécurité fiable”. L’argument suggère que l’accès aux données et l’isolement doivent s’appuyer sur des systèmes déterministes plutôt que sur des instructions du modèle.
Ce que cela change pour vos processus de rédaction
Au-delà du détail technique, l’histoire met en évidence un changement de perspective : lorsque des outils d’IA s’appuient sur des fichiers fournis pour produire un brouillon, les documents deviennent plus qu’un simple “support”. Ils peuvent devenir une source d’instructions réinterprétées.
Pour les équipes qui rédigent des rapports, des analyses ou des documents commerciaux, le réflexe à adopter consiste à contrôler la provenance des fichiers, à relire les sorties et à limiter la réutilisation aveugle de documents générés. Les cycles multiples — brouillon, relecture, édition, réexport — augmentent la probabilité que des éléments involontaires se retrouvent dans le contenu final.
Conclusion : Copilot pour Word nécessite une vigilance renforcée
Les faits rapportés montrent que Copilot pour Word peut, dans certaines conditions, recoder des instructions cachées provenant d’un document source dans un nouveau fichier généré, puis réappliquer ce comportement lors d’une session subséquente. L’attaque ne repose pas sur un malware classique, mais sur une manipulation du contexte d’entrée du modèle et de sa capacité à intégrer ce qu’il juge pertinent.
Pour réduire le risque, la recommandation la plus pragmatique reste la même : traiter les documents externes comme non fiables, vérifier le contenu avant et après génération, et garder un contrôle humain sur les éléments sensibles. À mesure que ces systèmes se généralisent, la sécurité documentaire devient un enjeu aussi opérationnel que technique.
Source: https://thehackernews.com/2026/07/microsoft-copilot-for-word-can-copy.html
