Reprompt : exfiltration en un clic depuis Copilot Personal via prompt prérempli dans l'URL

De quoi s’agit-il ?

Reprompt est une chaîne d’attaque contre Microsoft Copilot Personal divulguée par Varonis Threat Labs, dont l’analyse technique publique a d’abord été publiée le 14 janvier 2026 puis actualisée le 16 juin 2026 en parallèle d’une découverte connexe côté entreprise. Elle transforme un simple clic sur un lien Copilot d’apparence légitime en canal d’exfiltration silencieux : l’assistant lit le contexte de session et de profil de la victime et le fait fuiter, fragment par fragment, vers un serveur contrôlé par l’attaquant. Microsoft a confirmé que le problème est corrigé, et l’offre entreprise Microsoft 365 Copilot — protégée par le DLP du tenant et la gouvernance Purview — n’était pas affectée de la même manière.

Nous la traitons ici non comme une actualité de dernière minute, mais comme une étude de cas propre et entièrement remédiée. Deux de ses trois techniques sont des schémas de contournement qui se répètent bien au-delà de Copilot, et les comprendre est plus utile que la faille produit elle-même. Aucun payload fonctionnel n’est reproduit ci-dessous ; la valeur est dans les modes de défaillance.

Comment ça marche

Reprompt combine trois étapes. Aucune n’est une faille du modèle de langage sous-jacent — chacune est un défaut de conception et de validation dans l’application qui entoure le modèle.

La première est l’injection Paramètre-vers-Prompt (P2P). Copilot accepte un paramètre d’URL q qui préremplit le champ de saisie : un lien du type https://copilot.microsoft.com/?q=... amène l’assistant à traiter le texte embarqué comme si l’utilisateur l’avait saisi et validé. L’attaquant place ses instructions dans ce paramètre. L’utilisateur n’a qu’à cliquer ; la session déjà authentifiée fait le reste, sans nouvelle demande d’authentification. La même fonctionnalité de prompt prérempli a été documentée sur d’autres assistants — Tenable l’a décrite pour ChatGPT et LayerX pour le navigateur Comet de Perplexity — signe qu’il s’agit d’une classe de faiblesse, pas d’un cas isolé.

La deuxième est le contournement par double requête, et c’est la leçon la plus transférable. Copilot applique bien un garde-fou qui retire les données sensibles des requêtes URL sortantes — mais, dans la version vulnérable, ce contrôle ne s’exécutait que lors de la première exécution d’une instruction. En formulant la demande de sorte que l’assistant réalise chaque action deux fois et « compare » les résultats, l’attaquant déplaçait l’étape qui renvoie les données vers une seconde exécution que le filtre n’inspectait jamais. L’instruction exacte est [CAVIARDÉE] ; le point structurel est que le contrôle de sûreté et l’action n’étaient pas appliqués de façon symétrique d’une itération à l’autre.

La troisième est l’orchestration par chaîne de requêtes. Une fois le premier prompt exécuté, le serveur de l’attaquant répond avec des instructions de suivi qui dépendent de ce que Copilot a renvoyé — nom d’utilisateur, puis localisation, puis liste des fichiers récemment consultés, puis mémoire de conversation, fragment par fragment. Comme chaque instruction suivante est livrée par le serveur après le clic initial, inspecter le prompt de départ ne révèle rien de ce qui est réellement exfiltré, et la surveillance côté client ne voit qu’un flux de petites requêtes sortantes d’apparence banale.

Pourquoi c’est important

La combinaison correspond exactement à la « triade létale » que l’OWASP State of Agentic AI Security and Governance (v2.01, 11 juin 2026) place au cœur du risque agentique : un assistant disposant d’un accès à des données privées, d’une exposition à du contenu contrôlé par l’attaquant et de la capacité d’atteindre le réseau peut être transformé en outil d’exfiltration par une seule instruction injectée. Copilot réunit les trois par conception, car être utile suppose de détenir le contexte de l’utilisateur et de pouvoir aller chercher des choses.

Si les contournements se généralisent, c’est pour une raison architecturale. Comme le soulignent l’OWASP et Simon Willison, un modèle de langage reçoit le prompt système, la requête de l’utilisateur et tout texte externe sous la forme d’un même flux de tokens indifférencié — il n’existe pas de frontière fiable entre « commande » et « donnée ». Une URL préremplie n’est qu’une façon de plus de glisser du texte attaquant dans ce flux tout en revêtant l’autorité de l’utilisateur. Et l’astuce de la double requête rappelle qu’un garde-fou appliqué à un point du flux n’est pas un garde-fou appliqué au flux : partout où l’application est inégale entre relances, régénérations ou suivis, il y a un contournement.

Le schéma par chaîne de requêtes est la partie sur laquelle les défenseurs devraient s’attarder le plus. Il déjoue le contrôle intuitif — « inspecter le prompt avant exécution » — parce que les instructions dangereuses n’existent pas au moment du clic. Elles sont rédigées dynamiquement par un serveur distant en réponse à la sortie même du modèle. La détection doit passer du prompt au comportement.

Défenses

Les recommandations de Varonis, généralisées à tout assistant ou agent LLM qui ingère des entrées externes :

• Traitez toute chaîne fournie de l’extérieur comme une donnée non fiable, de bout en bout. Liens profonds, prompts préremplis, documents récupérés et sorties d’outils ne devraient jamais être promus au rang d’« instruction » sans une étape de conversion explicite et journalisée. Validez les paramètres de prompt préremplis au lieu de les exécuter au chargement de la page.
• Appliquez les garde-fous de façon symétrique sur tous les chemins d’exécution. Quel que soit le contrôle anti-fuite exécuté sur la première requête, il doit l’être à l’identique sur la deuxième, la relance, la régénération et chaque suivi enchaîné. Le bug, c’est l’application inégale, pas le prompt.
• Rendez la politique serveur et avec état, pas client et par-prompt. Comme l’exfiltration par chaîne de requêtes est invisible au prompt de départ, les contrôles doivent persister sur toute l’interaction et résider là où le modèle agit, pas dans l’onglet du navigateur.
• Appliquez le budget triade létale / Agents Rule of Two. Si un assistant peut lire un contexte privé, atteindre du contenu non fiable et sortir vers le réseau sans approbation, retirez l’un des trois : restreignez les requêtes sortantes à des destinations sur liste blanche, ou exigez une confirmation humaine avant que le modèle ne récupère des URL contrôlables par l’attaquant.
• Chassez sur le comportement, pas sur les payloads. Alertez sur les sorties initiées par l’assistant vers des points d’accès atypiques et sur de nombreuses petites requêtes sortantes séquentielles depuis un client IA — la signature d’une exfiltration incrémentale — plutôt que de compter sur l’inspection du prompt soumis par l’utilisateur.
• Pour les utilisateurs : traitez un lien qui ouvre un outil d’IA avec un prompt déjà rempli comme n’importe quel lien non sollicité, et lisez un prompt préchargé avant de le laisser s’exécuter.

Statut

Élément	Détail
Attaque	Reprompt (Varonis Threat Labs, chercheur Dolev Taler)
Cible	Microsoft Copilot Personal (grand public)
Non affecté	Microsoft 365 Copilot (entreprise, DLP/Purview du tenant)
Techniques	Injection P2P (paramètre q) · contournement par double requête · exfiltration par chaîne de requêtes
Analyse publique	14 janvier 2026 ; mise à jour le 16 juin 2026
Statut du correctif	Corrigé par Microsoft (cycle de mise à jour de janvier 2026) ; remédiation confirmée par l’éditeur
Exploitation active	Aucune exploitation de masse confirmée au moment de la divulgation ; démonstration de recherche
Connexe	SearchLeak — chaîne analogue dans M365 Copilot Enterprise (Varonis, juin 2026)
Nature	Étude de cas défensive — aucun payload d’exploitation reproduit