L’essentiel
- Le chercheur Håkon Måløy a montré qu’une injection de prompt visant Copilot pour Word pouvait se propager d’un document à l’autre.
- Les instructions cachées dans un fichier source sont recopiées par l’assistant dans le document qu’il rédige, qui devient porteur à son tour.
- Microsoft a disposé de 144 jours avant la publication, et aucun correctif ne couvre à ce jour l’ensemble de la classe d’attaque.
Quelques phrases écrites en blanc sur fond blanc, glissées dans un document Word que personne ne relit en entier : il n’en faut pas plus pour que Copilot se mette à exécuter les ordres d’un inconnu, puis à les recopier dans le fichier suivant. Aucune ligne de code exécutable là-dedans, seulement de la prose.
Håkon Måløy vient de décrire une variante d’injection de prompt qui, pour la première fois, se recopie elle-même pour se propager. Le terrain de jeu : Copilot pour Word, l’assistant qui rédige ou remanie un document en s’appuyant sur d’autres documents que vous lui fournissez.
Une instruction déguisée en document
Le mécanisme de départ est documenté depuis des années. L’injection de prompt consiste à glisser, dans un contenu que le modèle va lire, des phrases rédigées comme si elles venaient de l’utilisateur. Un modèle de langage n’a aucun moyen fiable de séparer « voici des données à traiter » de « voici ce que tu dois faire » : les deux arrivent dans la même fenêtre de contexte, sous la même forme, du texte.
Le camouflage, lui, est trivial. Texte blanc sur fond blanc, corps de caractère minuscule, note de bas de page que personne ne déroule : un lecteur humain ne voit rien, l’assistant lit tout. On retrouve le procédé jusque dans les CV que des candidats truffent de consignes destinées aux filtres de recrutement automatiques.
La consigne se recopie dans le document produit
Voilà où l’affaire change de catégorie. Dans le scénario décrit, l’attaquant place ses instructions dans un document qui finira par servir de source à Copilot pour Word. L’assistant les interprète comme une partie de la demande et modifie le document en cours de rédaction. Jusque-là, c’est de l’injection ordinaire : un fichier piégé, une victime, un effet.
Le pas supplémentaire tient à une consigne de plus : recopie-toi dans le document produit. Le livrable sort donc contaminé. Réutilisé la semaine suivante comme matière dans un autre travail assisté, il rejoue les instructions et les transmet au document suivant. La chaîne se poursuit alors que le fichier piégé d’origine ne circule plus nulle part. C’est la définition d’un ver, ce type de programme qui se propage de lui-même une fois lâché.
Les macro-virus qui ont empoisonné la bureautique des années 1990 viennent aussitôt à l’esprit. La différence de nature compte : le vecteur était alors un bout de code, et il a suffi de couper les macros par défaut pour assécher l’épidémie. Ici, la charge est de la prose, indiscernable d’un paragraphe légitime, et l’exécuteur est le modèle lui-même. Il n’existe pas de bouton « désactiver les instructions » comme il y avait un bouton « désactiver les macros ».
144 jours de délai, aucun correctif complet
La faille a fait l’objet d’une divulgation responsable auprès de Microsoft, qui a eu 144 jours pour travailler dessus avant publication. Deux correctifs, en avril puis en juillet, dont un passage à un modèle plus récent, n’ont pas refermé la classe d’attaque. Ce délai sans réponse complète en dit moins sur les équipes de l’éditeur que sur la nature du problème.
Un éditeur peut filtrer une formulation connue, détecter du texte rendu invisible, restreindre ce que l’assistant s’autorise à écrire dans un livrable. Chaque parade referme un chemin, pas la porte. Le problème vit un étage plus bas : tant que consignes et données circulent dans le même canal textuel, il n’y a pas de frontière à garder. La sécurité informatique classique sait isoler du code ; elle ne sait pas encore isoler du sens.
Microsoft n’est pas seul devant ce mur. Google affronte les mêmes injections indirectes dans Workspace, où quelques lignes cachées dans un e-mail suffisaient à détourner le résumé produit par Gemini, et son équipe sécurité écrit noir sur blanc que ce type de faille ne se règle pas une fois pour toutes. Sa réponse, elle aussi, empile les couches de défense faute de pouvoir fermer la brèche.
La note de cadrage devient un vecteur de contamination
Le point faible s’est déplacé sans qu’on y prenne garde. Nous avons passé deux ans à auditer les modèles : jailbreaks (contournements des garde-fous), alignement, filtres de sortie. Ce qui mérite l’attention désormais, c’est ce que ces modèles avalent, c’est-à-dire la note de cadrage, le compte rendu de réunion, la trame de présentation qui circule de service en service. Un assistant branché sur un espace partagé en mode RAG, autrement dit qui puise ses réponses dans une base documentaire maison, hérite exactement du même problème : cette base est alimentée par des documents que personne n’a relus ligne à ligne.
Quelques réflexes tiennent debout dès aujourd’hui :
- traiter tout document entrant comme une entrée non fiable, même signé par un collègue de confiance, parce que lui aussi a peut-être laissé un assistant y toucher ;
- surveiller ce que l’assistant écrit autant que ce qu’il lit : une sortie qui recopie des consignes est un signal en soi ;
- limiter les droits d’écriture des agents sur les espaces partagés, parce qu’un ver a d’abord besoin de circuler ;
- garder une relecture humaine sur les documents qui alimentent d’autres documents : modèles, trames, bases de connaissance internes.
Rien d’exotique dans cette liste : c’est de l’hygiène de flux, appliquée à un canal que nous n’avions pas pris l’habitude de considérer comme exécutable.
Une démonstration ne fait pas une épidémie, et rien n’indique à ce stade qu’une campagne exploite ce mécanisme dans la nature. Elle déplace en revanche une croyance confortable : la contamination n’a plus besoin de l’attaquant pour se poursuivre. Elle a seulement besoin que nous continuions à travailler comme nous le faisons, en repartant toujours du document d’à côté.
Mon avis
Nous avons branché des assistants sur nos documents partagés en gardant le modèle de confiance de l’époque où un fichier ne faisait rien tout seul, et je considère ce pari comme déjà perdu. Des scanners de contexte finiront par apparaître, chargés d’inspecter le texte avant qu’un modèle ne le lise, et je les crois d’avance aussi poreux que les antivirus de fichiers l’ont été. La seule parade solide consiste à réduire ce qu’un agent a le droit d’écrire, pas à espérer qu’il lise mieux. Tant que le secteur préférera empiler des filtres plutôt que retirer des permissions, ce genre de ver aura de beaux jours devant lui.
