Quand un document Word devient un vecteur d'attaque silencieux
Un chercheur en sécurité vient de démontrer qu'un fichier Word peut se transformer en ver informatique autonome, capable de se propager de document en document en exploitant Microsoft Copilot. Ce n'est pas de la science-fiction : la preuve de concept existe, Microsoft en a été informé dès le 31 mars, et après 144 jours sans correctif, le chercheur a rendu publiques ses conclusions. Pour toute organisation qui utilise l'IA pour traiter des documents externes, c'est une alerte concrète.
Comment fonctionne l'attaque : l'injection de prompt invisible
Le mécanisme imaginé par le chercheur Håkon Måløy repose sur une propriété bien connue des LLM : ils ingèrent le texte brut, sans tenir compte de la mise en forme visuelle.
L'attaquant insère des instructions malveillantes dans un document Word en utilisant du texte blanc sur fond blanc, à une taille de police infime. Pour un lecteur humain, la page semble parfaitement vierge. Mais Copilot, lorsqu'il analyse ce document comme source de contexte, supprime la couleur et la taille de police avant le traitement : il lit donc le texte caché comme s'il était parfaitement normal.
Dès que Copilot traite ce document — pour rédiger un résumé, en extraire des données ou l'utiliser comme base d'un nouveau fichier — les instructions cachées s'exécutent. Et la première instruction est simple : se recopier dans le nouveau document produit.
Le fichier généré devient à son tour porteur. Si un collaborateur l'utilise comme modèle pour un rapport financier, l'attaque se déclenche à nouveau. La chaîne peut être :
- Une analyse de marché téléchargée sur Internet (déjà infectée)
- Un rapport interne généré avec Copilot à partir de cette analyse
- D'autres rapports produits à partir du premier rapport
Chaque maillon de la chaîne propage silencieusement les instructions malveillantes.
Pourquoi c'est particulièrement préoccupant dans un contexte RAG
Cette attaque est d'autant plus dangereuse qu'elle cible précisément les workflows RAG (Retrieval-Augmented Generation), désormais très répandus en entreprise. Dans ces architectures, le modèle de langage consulte des documents externes pour enrichir ses réponses : bases documentaires internes, fichiers partagés sur SharePoint, pièces jointes reçues par email...
Le problème fondamental est que le LLM ne distingue pas les données du contexte des instructions de l'utilisateur. Une injection de prompt exploite exactement cette confusion : le modèle obéit aux instructions cachées dans les données comme s'il s'agissait de commandes légitimes.
Dans un scénario RAG, un seul document externe compromis peut potentiellement :
- Exfiltrer des informations contenues dans d'autres documents du corpus
- Manipuler les réponses fournies aux utilisateurs
- Se propager dans l'ensemble de la base documentaire au fil des générations de fichiers
Microsoft a confirmé le comportement et tenté deux correctifs, tous deux insuffisants. Le chercheur a publié ses conclusions avec retenue — il ne divulgue pas le contenu exact du payload — mais le principe est désormais public.
Ce que cela implique concrètement pour vos équipes
L'injection de prompt n'est pas un problème théorique réservé aux laboratoires de recherche. C'est un risque opérationnel immédiat pour toute organisation qui :
- Utilise Microsoft Copilot dans Word, Excel ou d'autres outils Office
- Intègre des documents externes dans ses workflows IA (appels d'offres, études sectorielles, rapports de partenaires)
- Génère des documents à partir de sources multiples via un pipeline RAG
Bonnes pratiques à mettre en place dès maintenant
1. Traiter les documents externes comme non fiables
Tout document qui n'a pas été produit en interne doit être considéré comme potentiellement compromis. Ne jamais l'utiliser directement comme source Copilot sans inspection préalable.
2. Inspecter les documents avant ingestion
Même sans outil automatisé, il est possible de détecter du texte caché dans Word : Format > Afficher tout, ou une extraction programmatique via des bibliothèques comme phpoffice/phpword en PHP pour vérifier le contenu brut avant indexation.
3. Sensibiliser les collaborateurs
Le vecteur principal reste humain : un collaborateur qui télécharge un rapport sectoriel sur Internet et l'injecte dans Copilot sans y penser. La formation à ces risques est aussi importante que les mesures techniques.
4. Auditer les pipelines RAG existants
Si votre organisation a mis en place un système RAG, auditez les sources d'alimentation : qui peut y déposer des documents ? Existe-t-il une validation des contenus avant indexation ?
5. Surveiller les comportements anormaux
Un document qui génère systématiquement des fichiers plus volumineux que prévu, ou qui contient des métadonnées inhabituelles, peut être un signal d'alerte.
Conclusion : la sécurité de l'IA demande une vigilance active
Ce que démontre Håkon Måløy, c'est que les vecteurs d'attaque évoluent aussi vite que les usages. L'injection de prompt reste à ce jour un problème non résolu dans l'industrie, et l'intégration de l'IA dans les outils du quotidien ouvre de nouvelles surfaces d'exposition.
Pour les équipes de développement qui conçoivent des applications intégrant des LLM, cela doit être un signal clair : la validation des entrées, principe fondamental en sécurité web depuis des décennies, s'applique aussi aux contenus ingérés par vos modèles. Traiter le prompt comme une entrée non fiable n'est pas du pessimisme — c'est de l'ingénierie responsable.
Source : The Decoder, Thomas Joos, 1er août 2026.
