Microsoft 365 Copilot : une redirection ouverte qui brouille la frontière entre locataires

De quoi s’agit-il ?

Le 2 juillet 2026, Microsoft a publié un avis de sécurité concernant une vulnérabilité d’élévation de privilèges dans Microsoft 365 Copilot, classée critique. Il s’agit d’une redirection ouverte — une URL que Copilot pouvait être amené à considérer comme fiable alors qu’elle pointait vers une destination non maîtrisée — dont la conséquence est inhabituelle pour cette classe de bug : elle pouvait permettre à un attaquant authentifié de franchir la frontière de confiance censée isoler les données d’un locataire (tenant) Microsoft 365 de celles d’un autre. Dans le pire scénario décrit par Microsoft, un compte à faibles privilèges dans une organisation pouvait atteindre des fichiers, des courriels ou des messages Teams appartenant à une organisation différente utilisant le même service Copilot. Microsoft a corrigé le problème côté service : aucun correctif n’est à installer par les clients. L’incident illustre néanmoins comment une faiblesse web banale devient sérieuse dès qu’un assistant LLM se place au milieu d’une chaîne d’autorisations.

Comment ça marche

Copilot n’est pas un simple modèle répondant à une question. C’est une couche d’orchestration qui diffuse une requête utilisateur à travers Microsoft Graph, SharePoint Online, Exchange et Entra ID, récupère ce que l’utilisateur est autorisé à voir, puis compose une réponse. Chacune de ces récupérations doit être autorisée au nom de l’utilisateur demandeur, au moment de la requête.

La vulnérabilité se logeait dans cette couture d’orchestration. Une redirection ouverte signifiait qu’un lien traité par l’assistant pouvait l’envoyer vers une destination influencée par l’attaquant tout en conservant l’apparence d’un flux interne et fiable. Selon l’avis public et les analyses qui ont suivi, cela a momentanément brouillé la distinction entre « données de ce locataire » et « données de cet autre locataire » : sous certaines conditions, le moteur d’orchestration traitait des contenus de locataires distincts comme s’ils relevaient du même domaine d’autorité. Comme Copilot journalise ses récupérations en tant qu’actions de l’application plutôt que de l’utilisateur, l’origine réelle d’une requête pouvait aussi être masquée — ce qui rend précisément cette classe de faille difficile à repérer a posteriori.

Aucun code d’exploitation n’est public, et nous n’en reproduisons pas. Le mécanisme importe plus que le payload : lorsqu’un assistant LLM dispose d’un accès en lecture large et inter-services, puis fait confiance à une redirection qu’il aurait dû revalider, la portée du modèle devient la portée de l’attaquant.

Pourquoi c’est important

Les redirections ouvertes sont habituellement classées « faible sévérité ». Ce qui change ici, c’est le rayon d’impact du composant situé derrière la redirection. Un copilote capable de raisonner sur l’ensemble du courrier, des documents et des conversations d’un locataire dispose, par construction, d’une vue très large sur des données sensibles. Une seule défaillance dans l’autorisation d’une requête ne fait pas fuir un fichier — elle peut exposer une tranche arbitraire d’un corpus, et ici potentiellement celui d’une organisation voisine. L’isolation entre locataires est l’une des promesses porteuses du SaaS multi-tenant ; un chemin d’élévation de privilèges qui la franchit, même brièvement, est une préoccupation de premier ordre pour tout environnement régulé.

La leçon plus large est architecturale. À mesure que les assistants deviennent l’interface par défaut vers les données d’entreprise, ils héritent et amplifient chaque erreur de configuration et chaque hypothèse de confiance sous-jacente. Un site SharePoint trop permissif, jusque-là risque latent, devient accessible dès qu’un copilote le fait remonter en réponse à une requête. Les équipes sécurité doivent désormais traiter les assistants IA comme des applications à forte valeur et à privilèges élevés, et les modéliser en conséquence — y compris via des exercices red team qui testent spécifiquement si une requête forgée ou un lien traité peut franchir une frontière entre locataires.

Défenses

Le correctif côté service supprime ce chemin précis, mais l’exposition qu’il a révélée est structurelle et mérite d’être durcie quoi qu’il arrive.

• Restreindre l’identité de l’assistant. Passez en revue les permissions accordées au principal de service Copilot dans Entra ID et retirez toute portée Graph à l’échelle du locataire dont il n’a pas besoin. Plus la portée de lecture de l’assistant est étroite, plus le rayon d’impact d’un futur dérapage d’autorisation est réduit.
• Durcir les données sous-jacentes. Auditez le partage externe et les permissions des sites SharePoint Online. Restreignez ou désactivez le partage externe sur les sites contenant des données sensibles : un copilote ne peut divulguer ce qu’il n’a jamais eu le droit d’indexer.
• Revoir les paramètres d’accès inter-locataires. Dans les identités externes Entra ID, examinez les configurations entrantes et sortantes et réduisez la confiance au strict nécessaire de votre collaboration B2B.
• Surveiller l’activité Copilot comme une source de journaux de premier plan. Dans le portail Microsoft 365 Defender, recherchez les requêtes renvoyant des données de sources inattendues ou des accès sans justification métier claire. Les actions étant journalisées au nom de l’application, concentrez-vous sur les schémas de récupération anormaux plutôt que sur la seule attribution utilisateur.
• Valider chaque redirection et réautoriser au moment de la récupération. Pour les équipes qui construisent leurs propres assistants LLM : ne laissez jamais le modèle suivre une redirection sur la confiance. Revalidez la destination finale et revérifiez l’autorisation au nom de l’utilisateur à chaque accès aux données, pas seulement à l’entrée.
• Modéliser la menace de l’assistant, pas seulement du modèle. Ajoutez « une requête ou un lien peut-il franchir une frontière de locataire ou de privilège ? » à votre plan de test, et traitez la couche d’orchestration — non les poids du LLM — comme la principale surface d’attaque.

Statut

La vulnérabilité a été divulguée et corrigée par Microsoft début juillet 2026. Aucune action client n’est nécessaire pour recevoir le correctif, mais le durcissement de configuration ci-dessus reste pertinent.

Élément	Détail
Produit affecté	Microsoft 365 Copilot (orchestration SharePoint Online, Exchange, Entra ID, Microsoft Graph)
Classe	Redirection ouverte → élévation de privilèges inter-locataires
Sévérité éditeur	Critique
Prérequis	Attaquant authentifié disposant d’un accès existant au locataire
Correctif	Appliqué côté service par Microsoft ; aucun patch client
Référence	CVE-2026-41106 (MSRC Security Update Guide)
Divulgation	~2 juillet 2026