Microsoft 365 Copilot SearchLeak (CVE-2026-42824) : Quand votre assistant IA devient un outil d’exfiltration
Des chercheurs en sécurité ont récemment démontré qu’un assistant IA d’entreprise pouvait être transformé en outil d’exfiltration de données de précision à l’aide d’un simple lien malveillant – et que la solution DLP de l’entreprise n’y voyait que du feu. Le CVE-2026-42824, désormais largement surnommé « SearchLeak » en raison du composant Bing SSRF au cœur de la faille, est une chaîne de vulnérabilités en trois étapes dans Microsoft 365 Copilot. Elle permet à un attaquant d’extraire des documents, des e-mails et des messages Teams d’une organisation cible sans avoir le moindre accès direct à l’environnement. Microsoft a corrigé la vulnérabilité et lui a attribué un score CVSS de 9,1, reflétant la faible complexité de l’attaque, l’absence de privilèges requis et la quantité de données accessibles.
La divulgation de SearchLeak va bien au-delà de sa gravité technique. Elle met en lumière un risque que les architectes sécurité dénoncent depuis l’arrivée des outils IA en production : donner à un grand modèle de langage un accès étendu aux données de l’organisation, puis l’exposer à des entrées externes, crée une surface d’attaque que les contrôles de sécurité classiques ne sont pas conçus pour gérer. Les outils sur lesquels les organisations comptent pour prévenir la fuite de données – DLP réseau, CASB, passerelles e-mail – ont été conçus pour un monde où les transferts de fichiers sont initiés par des humains. Ils n’ont aucun référentiel pour détecter un assistant IA qui récupère et encode des fichiers en réponse à une instruction cachée dans une page web.
Le contexte est également significatif. Le rapport annuel Kiteworks 2026 Data Security and Risk: Annual Forecast Report a identifié la gouvernance des données IA comme le défi de sécurité majeur de l’année, notant que les organisations déploient les outils IA plus vite qu’elles ne mettent en place les contrôles de gouvernance adaptés. SearchLeak est le premier CVE de cette gravité à valider ce constat à grande échelle. Ce ne sera pas le dernier.
Cet article détaille le fonctionnement de la chaîne d’attaque, les contenus à risque, pourquoi les contrôles existants échouent, et à quoi ressemble une posture de sécurité IA défendable après le CVE-2026-42824.
Résumé des points clés
1. Trois faiblesses combinées en une chaîne d’exploitation dévastatrice
Le CVE-2026-42824 n’est pas une faille isolée – il combine une vulnérabilité d’injection de prompt, une condition de concurrence lors du rendu HTML, et un contournement CSP basé sur Bing SSRF pour aboutir à une attaque fluide ne nécessitant qu’un simple clic sur un lien malveillant.
2. Les contrôles de détection classiques sont aveugles à l’attaque
Comme le canal d’exfiltration passe par l’infrastructure Bing de Microsoft, les outils de prévention des pertes de données, proxys réseau et solutions CASB ne signalent pas la requête sortante comme suspecte – le trafic ressemble à une télémétrie Copilot légitime.
3. Tous les locataires Microsoft 365 ayant activé Copilot sont potentiellement exposés
La vulnérabilité réside dans la couche de rendu partagée par Copilot pour Microsoft 365, ce qui signifie que l’exposition ne se limite pas à un module ou à un niveau de licence spécifique – toute organisation ayant activé Copilot doit considérer ce risque comme prioritaire.
4. Documents sensibles, e-mails et messages Teams sont concernés
L’index étendu de Copilot – incluant fichiers SharePoint, boîtes Exchange et historiques Teams – permet à une attaque réussie de faire remonter et exfiltrer pratiquement tout contenu accessible à l’utilisateur ciblé.
5. Le déploiement du correctif seul ne suffit pas
Bien que Microsoft ait publié un correctif, les organisations doivent l’accompagner d’une revue de leur gouvernance des données IA : quels contenus Copilot peut-il consulter, qui y a accès, et les sorties générées par l’IA sont-elles soumises aux mêmes exigences de traçabilité que les transferts de fichiers initiés par des humains ?
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Comment fonctionne la chaîne d’attaque SearchLeak
Comprendre SearchLeak suppose de comprendre comment Microsoft 365 Copilot traite les entrées externes et génère ses réponses. Copilot est conçu pour récupérer des informations dans tout l’environnement Microsoft 365 d’un utilisateur – SharePoint, OneDrive, Exchange, Teams – et les synthétiser sous forme de réponses en langage naturel. Pour cela, il a besoin d’un accès étendu aux contenus de l’organisation. Cette amplitude d’accès fait sa valeur, mais c’est aussi ce qui le rend dangereux lorsqu’un attaquant peut injecter des instructions dans le contexte du modèle.
Étape 1 : Injection de prompt via paramètre d’URL
La première faiblesse est une vulnérabilité d’injection de prompt via les paramètres d’URL lors de la navigation ou du clic sur un lien partagé dans Teams ou par e-mail. Lorsqu’une URL spécialement conçue est traitée, le texte contrôlé par l’attaquant dans le paramètre d’URL est injecté dans le contexte du prompt Copilot sans filtrage suffisant. L’attaquant peut ainsi glisser des instructions cachées dans un lien – pour demander à Copilot de récupérer des documents, résumer des e-mails ou rechercher dans l’historique Teams – qui seront exécutées comme si l’utilisateur les avait saisies lui-même.
L’injection de prompt est un risque IA bien connu – c’est l’équivalent d’une attaque XSS, où un contenu non fiable est traité comme une instruction de confiance. Ce qui rend SearchLeak particulièrement dangereux, c’est que l’injection ne nécessite aucune interaction dans la fenêtre de chat Copilot. Les instructions malveillantes sont délivrées passivement lors du chargement de la page dans le navigateur de l’utilisateur.
Étape 2 : Condition de concurrence lors du rendu HTML
La deuxième faiblesse est une condition de concurrence lors du rendu HTML dans la surface de réponse de Copilot. Quand Copilot génère une réponse incluant du HTML – utilisé pour l’affichage enrichi dans certaines intégrations – il existe une fenêtre temporelle où du HTML contrôlé par l’attaquant peut s’exécuter avant l’application complète des restrictions CSP. Les chercheurs ont exploité cette fenêtre pour injecter une balise dont l’attribut src encode les données exfiltrées en paramètres de requête.
Le CSP est censé empêcher ce type d’exfiltration en limitant les domaines externes qu’une page peut contacter. C’est là qu’intervient la troisième étape de la chaîne.
Étape 3 : Contournement CSP via Bing SSRF
La troisième faiblesse est une vulnérabilité SSRF (Server-Side Request Forgery) dans la façon dont Copilot relaie les requêtes via l’infrastructure Bing de Microsoft. Copilot communique légitimement avec Bing pour certaines opérations de recherche, ce qui place le point de terminaison Bing sur la liste blanche CSP. Les chercheurs ont découvert qu’en routant la requête d’exfiltration via une URL Bing spécialement construite, ils pouvaient faire transiter les données volées par un point de sortie explicitement autorisé par le CSP.
Résultat : la balise de l’attaquant s’exécute, encode le contenu du document dans les paramètres d’URL, et la requête passe par Bing – apparaissant comme un trafic Copilot-Bing normal pour tout outil réseau. Les données quittent l’organisation en toute discrétion.
Quels types de données sont à risque
L’étendue de l’exfiltration SearchLeak dépend de ce que Copilot peut consulter – pour les organisations n’ayant pas restreint l’index Copilot, cela correspond à tout ce que l’utilisateur ciblé peut voir dans Microsoft 365.
Les chercheurs ont démontré la récupération de contenus de bibliothèques SharePoint, de corps d’e-mails Exchange (y compris pièces jointes), de messages directs et conversations Teams, et de fichiers OneDrive. En production, cela signifie de la propriété intellectuelle stockée dans SharePoint, des informations personnelles identifiables (PII)/informations médicales protégées (PHI) dans des échanges e-mail avec patients ou clients, des communications juridiques, des documents de fusion-acquisition dans des data rooms virtuelles, et des contenus réglementés soumis à la HIPAA, au RGPD ou à la CMMC.
L’attaque est ciblée : l’instruction injectée peut contenir des requêtes précises. Un attaquant connaissant l’environnement cible – via LinkedIn ou une phase de reconnaissance – peut demander à Copilot de récupérer des documents sur des termes spécifiques. « Trouver les e-mails concernant des cibles d’acquisition sur les 90 derniers jours » ou « récupérer les derniers contrats du site SharePoint juridique » sont des exemples d’instructions injectables. L’attaque n’est donc pas limitée à une exfiltration massive et aveugle ; elle peut être chirurgicale.
C’est pourquoi la question DSPM est si urgente. Les organisations qui n’ont pas inventorié leurs contenus sensibles dans Microsoft 365, ni ce qu’un utilisateur – ou Copilot agissant en son nom – peut consulter, opèrent à l’aveugle. La gouvernance des données, le contrôle des accès et la limitation des droits ne sont pas ici de simples exigences de conformité : ils sont indispensables pour comprendre et limiter le périmètre d’exposition.
Pourquoi les contrôles de sécurité existants échouent face à SearchLeak
L’attaque SearchLeak est spécifiquement conçue pour contourner les catégories de contrôles sur lesquelles la plupart des organisations s’appuient pour éviter l’exfiltration de données. Ce n’est pas un hasard : elle exploite une connaissance fine des failles des outils de sécurité d’entreprise dès lors que l’IA entre en jeu.
Limites des DLP réseau et CASB.
Les DLP et CASB inspectent le trafic sortant à la recherche de données sensibles – numéros de sécurité sociale, cartes bancaires, structures de documents connues. Mais avec SearchLeak, les données exfiltrées sont encodées dans les paramètres d’URL d’une requête Copilot-Bing légitime. La plupart des outils DLP ne sont pas configurés pour inspecter en profondeur les paramètres d’URL dans le trafic Microsoft autorisé. Même ceux qui le font devraient décoder le schéma d’encodage pour identifier la transmission d’un document, ce qui suppose de connaître à l’avance le mode opératoire de l’attaque.
Limites des passerelles e-mail et des proxys.
L’attaque ne passe pas par l’e-mail comme canal d’exfiltration. Elle ne nécessite aucun transfert de fichier sortant détectable par un proxy. Tout le chemin d’exfiltration est une requête HTTP GET vers une URL Bing, lancée par le navigateur lors du rendu d’une réponse Copilot. Les outils proxy standards voient une requête Microsoft-Microsoft et l’autorisent.
Limites des DLP endpoint.
Les agents endpoint surveillant l’accès aux fichiers ou le presse-papiers ne détecteront pas cette attaque, car aucun fichier n’est ouvert, copié ou transféré via un canal surveillé. L’accès au fichier s’effectue entièrement dans la couche service de Copilot.
Limites des SIEM et de l’analytique comportementale.
Les plateformes SIEM et d’analyse comportementale recherchent des schémas d’activité utilisateur anormaux. Une session Copilot qui récupère une douzaine de documents et envoie une requête GET à Bing ressemble à une utilisation normale de Copilot. Sans règle de détection spécifique du schéma SearchLeak, ces outils ne génèrent aucune alerte.
Le constat est inconfortable : les organisations ayant déployé Copilot avec des contrôles de sécurité classiques ont une faille. La combler nécessite des investissements sécurité spécifiquement conçus pour les accès IA, et pas seulement des extensions des contrôles adaptés à l’activité humaine.
Le problème de gouvernance révélé par SearchLeak
SearchLeak serait déjà une vulnérabilité sérieuse dans une application classique. Dans Microsoft 365 Copilot, elle révèle un enjeu plus profond : l’infrastructure de gouvernance nécessaire pour déployer l’IA de façon responsable dans des environnements réglementés n’a pas suivi le rythme d’adoption de l’IA.
Le principal déficit de gouvernance concerne l’ABAC et la limitation des droits d’accès. La plupart des organisations déploient Copilot avec les paramètres par défaut, donnant à Copilot accès à tout ce que l’utilisateur peut voir. Pour un dirigeant ayant de larges droits SharePoint, cela signifie que Copilot – et donc tout attaquant capable d’injecter des prompts – peut accéder à la même quantité de contenus sensibles. Une gouvernance des données efficace impose que les outils IA appliquent le principe de minimisation des données : n’accéder qu’aux contenus nécessaires à la tâche, pas à tout ce que l’utilisateur peut consulter.
Le deuxième déficit de gouvernance concerne la traçabilité. Lorsqu’un employé accède à un document sensible, l’accès est journalisé dans SharePoint et les plateformes DLP peuvent le corréler à d’autres activités. Quand Copilot accède au même document pour le compte d’un utilisateur – surtout si l’accès est déclenché par une instruction injectée et non une action volontaire – la traçabilité est fragmentée dans plusieurs journaux rarement corrélés. Un attaquant utilisant SearchLeak pour exfiltrer 50 documents laissera des traces dans les logs Copilot, Bing et SharePoint – mais les relier suppose une visibilité unifiée que peu d’entreprises possèdent.
Le troisième déficit de gouvernance concerne l’application des règles au niveau IA. Les politiques DLP sont appliquées au niveau du système de fichiers, des passerelles e-mail ou des endpoints. Il n’existe pas d’équivalent au niveau des interactions IA – aucun contrôle ne dit « Copilot ne doit pas récupérer de documents confidentiels ni inclure leur contenu dans une réponse HTML ». Ce type de gouvernance IA nécessite une infrastructure de sécurité IA dédiée, avec la même rigueur que pour la conformité réglementaire : systématique, traçable, et appliquée en continu.
À quoi ressemble une réponse défendable
Corriger le CVE-2026-42824 est un prérequis, mais ce n’est pas suffisant. Se contenter du correctif ferme cette faille spécifique mais laisse les déficits de gouvernance ouverts pour la prochaine. Une réponse défendable repose sur quatre volets.
- Appliquer le correctif immédiatement. Le correctif Microsoft pour CVE-2026-42824 doit être déployé en priorité. Les organisations utilisant Copilot dans des environnements réglementés – sous CMMC 2.0, HIPAA, RGPD ou FINRA – doivent traiter ce cas comme un zero-day, même si le correctif est disponible, compte tenu de la gravité et de la probabilité que l’exploitation ait eu lieu avant la divulgation.
- Limiter l’accès de Copilot aux données. Passez en revue les labels de sensibilité SharePoint, les structures d’autorisations et la configuration des accès Copilot dans votre tenant Microsoft 365. Appliquez le principe de minimisation des données : Copilot ne doit accéder qu’aux contenus dont l’utilisateur a réellement besoin pour son rôle, pas à tout ce que ses droits Microsoft 365 permettent. La classification des données est ici indispensable – sans étiquetage des contenus sensibles dans SharePoint et Exchange, il est impossible de limiter ce que Copilot peut restituer. La documentation Microsoft sur la gouvernance Copilot détaille les bonnes pratiques. Si les labels de sensibilité ne sont pas appliqués partout, il est urgent d’accélérer ce chantier.
- Mettre en place visibilité et contrôle au niveau IA. Les outils de gouvernance des données IA dédiés – comme la Kiteworks AI Data Gateway – apportent la couche de visibilité et d’application des règles qui manque aux DLP et CASB généralistes. L’AI Data Gateway applique les politiques d’accès aux données au point d’interaction entre l’IA et les contenus de l’organisation, impose des contrôles ABAC sur ce que l’IA peut restituer, et journalise les accès IA dans la même traçabilité que les activités humaines. C’est la réponse architecturale aux déficits de gouvernance révélés par SearchLeak, pas un simple patch tactique.
- Réaliser un audit post-incident pour détecter une éventuelle exploitation. Étant donné que CVE-2026-42824 était exploitable avant la publication du correctif, il faut analyser les logs Copilot, SharePoint et Bing pour la période antérieure au patch. Recherchez notamment les sessions Copilot ayant récupéré un volume inhabituel de documents, celles déclenchées par des clics sur des liens externes, et les requêtes Bing avec des paramètres d’URL anormalement volumineux. Formaliser un plan de réponse à incident couvrant les scénarios d’exfiltration IA permettra de réagir rapidement en cas de compromission avérée. Ce n’est pas une garantie de détection – l’attaque a été conçue pour passer inaperçue – mais c’est une démarche de diligence, surtout pour les organisations soumises à des obligations réglementaires de notification.
La leçon à retenir : la sécurité IA n’est pas une extension de la sécurité existante
Le CVE-2026-42824 doit servir de déclencheur à une discussion que l’industrie de la sécurité repousse depuis trop longtemps. Les outils et architectures conçus pour protéger les données contre l’exfiltration humaine ne suffisent pas à les protéger lorsqu’un assistant IA y accède, et que des attaquants peuvent injecter des instructions dans cet assistant.
Le problème n’est pas que Microsoft ait conçu un produit vulnérable – tout logiciel complexe a des failles, et la réaction de Microsoft a été appropriée. Le problème, c’est que les contrôles de sécurité déployés avec Copilot reposent sur un modèle de menace fondamentalement différent. Ils partent du principe que les données sortent via des actions humaines – téléchargements, pièces jointes, clés USB, uploads web. Ils ne sont pas conçus pour détecter ou empêcher un assistant IA de récupérer et encoder du contenu suite à un prompt injecté.
Ce dont les organisations ont besoin, c’est d’un modèle Réseau de données privé pour l’accès IA : appliquer les principes de la zero trust architecture à chaque interaction entre l’IA et les données de l’organisation. Cela implique de faire respecter la minimisation des données au niveau IA, de journaliser chaque accès IA dans un journal d’audit unifié, d’appliquer des politiques de sensibilité sur ce que l’IA peut restituer, et de développer des capacités de détection spécifiques aux attaques IA.
Les organisations qui voient SearchLeak comme un simple problème de patch s’exposent à la même faille lors du prochain CVE de la même catégorie. Celles qui en font un catalyseur pour bâtir une véritable gouvernance IA – avec des cadres conformes imposant les règles au niveau du modèle – seront bien mieux armées, tant face aux futures vulnérabilités que face aux régulateurs qui examineront de plus en plus l’accès IA aux données comme un domaine de conformité à part entière.
Pour en savoir plus sur la protection des données sensibles contre l’exfiltration IA, réservez votre démo sans attendre !
Foire aux questions
Le CVE-2026-42824 est une vulnérabilité critique (CVSS 9,1) dans Microsoft 365 Copilot qui combine trois faiblesses distinctes : une faille d’injection de prompt via paramètre d’URL permettant à des instructions contrôlées par l’attaquant d’être injectées dans le contexte Copilot, une condition de concurrence lors du rendu HTML qui crée une fenêtre où du HTML injecté peut s’exécuter avant l’application des restrictions CSP, et une vulnérabilité SSRF côté serveur permettant à l’exfiltration de passer par l’infrastructure Bing de Microsoft – un domaine autorisé par toutes les CSP d’entreprise. Résultat : un utilisateur qui clique sur un lien malveillant peut voir ses documents, e-mails et messages Teams récupérés silencieusement par Copilot et exfiltrés vers un serveur contrôlé par l’attaquant, sans interaction visible avec Copilot et sans déclencher les contrôles DLP ou CASB classiques. Comprendre cette classe d’attaque suppose de repenser la gestion du risque sécurité dans les environnements IA.
Toute organisation ayant activé Microsoft 365 Copilot et n’ayant pas encore appliqué le correctif est à risque. L’exposition est particulièrement forte pour celles qui stockent de grands volumes de contenus sensibles dans Microsoft 365 – notamment les établissements de santé avec des informations médicales protégées (PHI) dans Exchange et SharePoint, les sous-traitants de la défense avec des CUI soumis à NIST 800-171 et CMMC, les sociétés financières avec des données clients réglementées, et les cabinets juridiques avec des communications confidentielles. Pour ces organisations, une exploitation réussie peut déclencher une réponse à incident réglementaire et des obligations de notification, faisant du correctif une priorité sécurité et conformité. Les organisations soumises à l’EU AI Act sont également plus exposées, cette réglementation considérant de plus en plus les failles IA comme un échec de gouvernance nécessitant une remédiation documentée.
L’attaque est conçue pour ressembler à un trafic Copilot-Bing légitime. L’exfiltration se fait via une requête HTTP GET vers une URL Bing, lancée par le navigateur lors du rendu d’une réponse Copilot – une transaction indiscernable d’une recherche Copilot classique au niveau réseau. Les outils DLP standards inspectant le trafic sortant pour détecter des données sensibles ne sont pas configurés pour analyser en profondeur les paramètres d’URL dans le trafic Microsoft autorisé, et même ceux qui le font devraient connaître le schéma d’encodage spécifique utilisé par SearchLeak pour identifier les données volées. La leçon n’est pas que DLP et CASB sont inutiles – ils protègent contre de nombreux scénarios d’exfiltration – mais que des contrôles de gouvernance des données IA dédiés sont nécessaires pour contrer les vecteurs d’attaque propres à l’IA. Ce manque concerne aussi la conformité : les organisations ne peuvent prouver que les données réglementées sont restées protégées si leurs outils de surveillance n’ont rien vu du canal d’exfiltration.
La priorité immédiate est d’appliquer le correctif Microsoft pour CVE-2026-42824. Au-delà du patch, il faut revoir le périmètre d’accès de Copilot – en particulier quels sites SharePoint, boîtes mail et canaux Teams Copilot peut consulter pour chaque utilisateur, et si ce périmètre correspond à un besoin réel ou à une permissivité par défaut. Il convient aussi d’examiner les logs d’audit Microsoft 365 pour la période précédant le patch, à la recherche de sessions Copilot anormales ou de requêtes sortantes compatibles avec le schéma d’exfiltration SearchLeak. Les organisations soumises à des obligations réglementaires (HIPAA, RGPD, CMMC) doivent consulter leurs équipes juridiques et conformité pour déterminer si la période d’exposition potentielle impose une notification ou une documentation. Une évaluation des risques spécifique à l’accès IA doit être menée avant toute réactivation ou extension de Copilot.
La Kiteworks AI Data Gateway comble les déficits de gouvernance révélés par le CVE-2026-42824 au niveau architectural. Elle applique les politiques ABAC et de minimisation des données au point d’interaction entre l’IA et les contenus de l’organisation, garantissant que les modèles n’accèdent qu’aux contenus cohérents avec le rôle de l’utilisateur et le contexte de la tâche – et non à tout ce que ses droits permettent. Chaque accès IA est journalisé dans le journal d’audit unifié de Kiteworks, offrant la visibilité nécessaire pour détecter des activités IA anormales, prouver la conformité et investiguer d’éventuels incidents. Le CISO Dashboard offre une visibilité en temps réel sur les contenus consultés par l’IA dans toute l’organisation, permettant la gestion des risques que SearchLeak rend incontournable dans l’entreprise IA. Les organisations souhaitant étendre ces protections à des workflows IA personnalisés peuvent aussi utiliser le Kiteworks Secure MCP Server pour appliquer les mêmes politiques de gouvernance sur leurs intégrations de modèles.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée face à l’IA - Article de blog
Pourquoi 77 % des organisations échouent à sécuriser leurs données face à l’IA - eBook
L’écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.