SearchLeak : Un simple clic sur un lien Microsoft suffisait à siphonner vos données

En juin 2026, les chercheurs de Varonis Threat Labs ont levé le voile sur une vulnérabilité qui ressemble plus à un scénario de film d'espionnage qu'à un banal rapport de CVE. Surnommée SearchLeak, cette chaîne d'exploitation dans la recherche d'entreprise de Microsoft 365 Copilot permettait d'aspirer les données les plus sensibles d'un utilisateur — emails, codes de validation MFA à usage unique, liens de réinitialisation de mot de passe et fichiers indexés — en un simple et unique clic sur un lien légitime microsoft.com . Pas de formulaire de mot de passe, pas de second clic, pas de demande explicite. L'attaque était invisible pour les filtres anti-hameçonnage, car elle résidait sur le propre domaine de Microsoft .

Attribuée au code CVE-2026-42824 avec une sévérité « critique » par Microsoft, la vulnérabilité a été corrigée côté serveur avant toute exploitation connue. Les clients n'ont rien eu à faire . La véritable histoire ne réside pourtant pas dans le correctif, mais dans l'ingénieuse chaîne en trois étapes qui l'a rendue possible, et ce qu'elle révèle sur la sécurisation des outils d'entreprise dopés à l'IA.

Pourquoi SearchLeak est un tournant

SearchLeak n'était pas un bug unique et cataclysmique. C'était l'enchaînement de trois faiblesses plus modestes, soigneusement exploitées en séquence. Prises isolément, aucune n'aurait été dramatique. Ensemble, elles formaient un pipeline d'exfiltration silencieux en un clic, capable d'atteindre tout ce que l'utilisateur connecté pouvait consulter via Microsoft Graph : emails, invitations de calendrier, notes de réunion, documents SharePoint et fichiers OneDrive .

Cette découverte a surtout mis en lumière un schéma récurrent contre lequel les experts en sécurité alertaient. En janvier 2026, le même laboratoire de Varonis avait divulgué Reprompt, une attaque presque identique en un clic contre la version grand public Copilot Personnel . Encore plus tôt, en juin 2025, Aim Security avait révélé EchoLeak, une vulnérabilité zero-clic qui utilisait une injection de prompt cachée dans un document malveillant . L'arrivée de SearchLeak a démontré que les garde-fous de niveau entreprise n'avaient pas éliminé cette classe de risques sous-jacents — ils en avaient seulement relevé la barre, forçant les attaquants à faire preuve de plus de créativité.

L'enchaînement des trois failles

Chaque maillon de la chaîne SearchLeak est instructif en soi, mais c'est leur effet combiné qui a rendu l'attaque si redoutable.

Étape 1 : L’injection de paramètre en instruction (P2P)

La recherche d'entreprise de Copilot accepte un paramètre d'URL — q — qui contient la question en langage naturel de l'utilisateur. Les chercheurs de Varonis ont découvert que ce paramètre n'acceptait pas seulement une phrase de recherche : il acceptait des instructions arbitraires .

Un attaquant pouvait ainsi concevoir une URL qui, une fois chargée par un utilisateur authentifié, ordonnait à Copilot de faire quelque chose de complètement différent de ce que le lien semblait indiquer. Par exemple, un lien pouvait demander à l'IA de chercher un code MFA à usage unique dans la boîte mail de la victime, d'intégrer ce code dans l'URL d'une image, et de l'ajouter à la réponse. La victime voyait une page de recherche au logo Microsoft. Copilot obéissait silencieusement à l'instruction injectée .

Cette technique, que Varonis appelle injection Parameter-to-Prompt (P2P), était le même mécanisme au cœur de l'attaque antérieure Reprompt contre Copilot Personnel .

Étape 2 : Une condition de concurrence qui contourne l'assainissement

Lorsque Copilot génère une sortie incluant du code HTML (comme une balise <img>), un filtre d'assainissement côté serveur est censé encapsuler cette sortie dans des blocs de code pour que le navigateur la traite comme du texte brut inoffensif. Le problème ? Cet encapsulage n'intervient qu'après la génération complète du contenu .

Or, le navigateur commence à afficher la réponse pendant qu'elle est encore en train d'être diffusée. La balise <img> injectée par l'attaquant émet donc sa requête dès qu'elle apparaît dans le flux — avant même que le filtre n'ait eu le temps d'agir. Le temps que le bloc de code apparaisse, l'URL de l'image a déjà été sollicitée et les données encodées dans son chemin ont déjà quitté le navigateur de la victime .

Il s'agit d'une condition de concurrence classique, rendue redoutable par le contexte du contenu généré par l'IA. Un ancien mécanisme de défense n'avait pas été repensé pour un monde où la sortie de l'IA est elle-même contrôlable par un attaquant.

Étape 3 : L’exfiltration via un point de terminaison Bing autorisé par la CSP

Même avec les deux premières étapes en place, un dernier obstacle se dressait : la politique de sécurité du contenu (CSP) sur le domaine m365.cloud.microsoft bloque les images provenant de serveurs externes arbitraires. Cependant, *.bing.com est dans la liste d'autorisations .

Le point de terminaison « Recherche par image » de Bing permet d'aller chercher une URL côté serveur. Dans l'exploit SearchLeak, l'attaquant ajoutait les données volées dans le chemin de recherche d'image (par exemple,

https://www.bing.com/images/search?q=/Votre_Code_Securite_847291/img.png

L'attaquant n'avait plus qu'à surveiller les logs de son propre point de terminaison d'image, que le serveur de Bing avait été piégé de contacter.

La simplicité trompeuse d'un simple clic

Toute la chaîne s'exécutait automatiquement. Une victime cliquait sur un lien. Copilot effectuait une recherche dans ses propres données. Le résultat était diffusé vers le navigateur. Une balise <img> se déclenchait. Le serveur de Bing contactait l'URL de l'attaquant. Les données étaient exfiltrées. Tout cela se produisait avant que le navigateur de l'utilisateur n'ait fini d'afficher la page.

L'attaque était difficile à détecter pour plusieurs raisons :

• L'URL était sur un domaine Microsoft de confiance, déjouant les scanners d'URL et les contrôles de réputation .
• Aucune boîte de dialogue d'authentification ni second clic n'était déclenché — la session existante de la victime était utilisée.
• Toutes les requêtes sortantes étaient dirigées vers l'infrastructure Microsoft autorisée.

Les données qui pouvaient être volées n'avaient rien de théorique. Les chercheurs ont mis en avant les codes MFA à usage unique et les liens de réinitialisation de mot de passe, valides pendant plusieurs minutes, ainsi que des détails de calendrier et des documents sensibles indexés par Copilot .

Le casse-tête de la sévérité : Critique, mais quel score ?

Le CVE-2026-42824 a suscité un mini-débat sur les scores de gravité. Microsoft a attribué à cette vulnérabilité son plus haut niveau de sévérité interne — Critique — mais a publié un score de base CVSS v3.1 de 6,5 (Moyen). La raison : l'attaque nécessitait une interaction de l'utilisateur (le simple clic), ce qui a réduit le score .

Certaines sources ont rapporté un score de 7,5 (Élevé) de la part de la National Vulnerability Database (NVD) . En pratique, cependant, plusieurs revues, dont l'analyse de TNW, ont noté que le fichier CSAF de Microsoft et l'entrée NVD reflétaient un vecteur identique de 6,5 . La perception d'un score plus élevé pourrait provenir d'analystes indépendants qui ont calculé sous des hypothèses d'impact plus larges ou qui ont fait écho à des rapports initiaux.

Quel que soit le chiffre, le consensus était clair : un simple clic pouvait exposer les données les plus sensibles d'une organisation.

La généalogie des vulnérabilités de Copilot

SearchLeak n'est pas apparu dans le vide. Elle rejoint deux autres découvertes majeures d'exfiltration par IA :

• EchoLeak (CVE-2025-32711) — Juin 2025. Une vulnérabilité zero-clic découverte par Aim Security, utilisant une injection de prompt intégrée dans un document que Copilot traitait automatiquement. Aucune interaction de l'utilisateur nécessaire. CVSS 9.3 .
• Reprompt — Janvier 2026. Varonis a montré que la version grand public Copilot Personnel pouvait être détournée avec la même technique d'injection P2P. Pas de malware, pas d'extension, juste une URL fabriquée .

Le fil conducteur est l'injection de prompt, une menace qui transforme la capacité fondamentale de l'IA — suivre des instructions — en une surface d'attaque. Chaque vulnérabilité suivante a montré que corriger une surface (Grand Public contre Entreprise) ou ajouter des garde-fous (traitement des documents contre requêtes de recherche) n'élimine pas la classe de vulnérabilité, mais ne fait que rediriger la créativité des attaquants .

Ce que les administrateurs doivent faire maintenant

La faille SearchLeak elle-même est corrigée et ne nécessite aucune action de la part des clients. Mais la technique n'a pas disparu, et les équipes de sécurité doivent en tirer les leçons opérationnelles.

Surveiller les URL de recherche Copilot. Le paramètre q est toujours exposé. Soyez attentifs à la présence de code HTML encodé, de charges utiles ressemblant à des scripts, ou de chaînes d'instructions suspectes et longues dans les URL de recherche d'entreprise de Copilot transitant par vos logs de proxy .

Surveiller les requêtes sortantes anormales vers les points de terminaison d'images Bing. Un utilisateur générant soudainement de multiples requêtes vers *.bing.com avec des chemins de recherche d'image inhabituels — en particulier des motifs ressemblant à des données encodées ou exfiltrées — doit déclencher une alerte .

Limiter la surface de données indexée par Copilot. Adoptez une gouvernance des données basée sur le principe du moindre privilège. Restreignez les sites SharePoint, dossiers OneDrive et boîtes mail que Copilot peut indexer, afin qu'une future vulnérabilité ne se traduise pas par le vol de tout ce que l'utilisateur peut atteindre. Auditez et réduisez régulièrement les autorisations Microsoft Graph de Copilot .

La divulgation de SearchLeak n'est pas l'histoire d'un simple correctif, mais un avertissement sur l'intersection évolutive entre l'injection de prompt et les vulnérabilités web classiques. Alors que les organisations adoptent des assistants IA ayant un accès profond à leurs données, les modèles de sécurité qui traitent le contenu généré par l'IA comme digne de confiance doivent être fondamentalement repensés. La prochaine chaîne n'utilisera pas les trois mêmes bugs — mais elle réutilisera presque certainement le même schéma.