CVE-2026-35435 : les agents M365 publiés depuis Azure AI Foundry faisaient confiance à des appelants qu'ils auraient dû refuser

De quoi parle-t-on ?

Le 7 mai 2026, Microsoft a divulgué CVE-2026-35435, une vulnérabilité d’élévation de privilèges dans Azure AI Foundry qui touche les agents Microsoft 365 publiés. La faille est notée CVSS 8.6 (CRITIQUE) et classée CWE-284 — Improper Access Control. D’après l’avis Microsoft et les reprises par Qualys, SecurityWeek et CybersecurityNews, la divulgation accompagne le Patch Tuesday de mai 2026 et Microsoft décrit le problème comme exploité dans la nature. Au moment de la publication, aucun correctif complet n’était disponible ; Microsoft a publié à la place un jeu de mesures compensatoires.

Le bug se trouve dans le chemin d’autorisation des agents publiés depuis Azure AI Foundry vers Microsoft 365. Un attaquant distant non autorisé peut contourner les contrôles d’accès du runtime et passer d’un rôle faiblement privilégié à un rôle disposant d’un contrôle étendu sur les workflows de l’agent, ses connecteurs de données et les ressources auxquelles l’agent était relié.

Comment ça marche

Azure AI Foundry permet aux organisations de construire des agents pilotés par LLM — assistants de recherche, triage de tickets, analyseurs de documents — et de les publier dans les surfaces Microsoft 365 (Teams, Outlook, SharePoint, points d’extrémité Copilot). Une fois publié, l’agent s’exécute avec un service principal qui détient les permissions déléguées sur les connecteurs et les sources de données qu’on lui a confiés au moment de sa conception.

CVE-2026-35435 vit dans la couche d’autorisation qui filtre les appels vers cet agent publié au runtime. D’après plusieurs analyses citant l’avis Microsoft, le runtime de l’agent ne liait pas systématiquement l’identité et le rôle de l’appelant à une session côté serveur. Le matériel d’identité fourni par l’appelant — ou son absence — était considéré comme une preuve suffisante d’autorisation. Le résultat, dans la langue de CWE-284, est que l’agent acceptait des requêtes venant de principals qui auraient dû être rejetés et les acheminait dans des workflows réservés à des rôles de niveau owner.

Concrètement, les actions post-exploitation décrites dans la couverture publique incluent : republier ou modifier la configuration d’un agent avec des permissions élevées, abuser des intégrations Microsoft 365 existantes de l’agent pour lire des courriers et des fichiers ou se faire passer pour l’utilisateur au nom duquel l’agent parlait, et pivoter latéralement dans un workspace Azure AI Foundry vers d’autres agents et services connectés.

# Classe conceptuelle — illustratif, pas du code d'exploitation
appelant ─▶ runtime de l'agent
              ├── fait confiance à l'identité revendiquée par l'appelant   ❌
              └── route l'appel vers un workflow de niveau owner
                  ├── modifier la config de l'agent
                  ├── réutiliser les permissions M365 déléguées (mail, fichiers)
                  └── pivoter vers les agents voisins du workspace

La vulnérabilité ne demande aucune interaction utilisateur et est atteignable via le réseau. C’est un pur bug d’autorisation — pas de corruption mémoire, pas de prompt injection — mais il est posé sur un runtime d’agent LLM, donc le rayon de souffle est dimensionné par tout ce que l’agent était autorisé à faire pour le compte de l’utilisateur.

Pourquoi c’est important

Trois points méritent d’être posés.

D’abord, l’identité est désormais la surface d’attaque des agents LLM. Le modèle lui-même n’est pas la vulnérabilité. La vulnérabilité, c’est la façon dont le runtime décide qui parle à l’agent et quel rôle a cet appelant. C’est la même classe d’échec qui a frappé la pile Microsoft à deux reprises ces dernières semaines : CVE-2026-32173 sur Azure SRE Agent (avril 2026) faisait confiance à un contrôle de token multi-tenant qu’il n’aurait pas dû faire ; CVE-2026-35435 fait confiance à l’identité de l’appelant pour les agents M365 publiés. Deux produits différents, même leçon — c’est l’identité privilégiée de l’agent qui est la cible.

Ensuite, les agents publiés sont une flotte, pas une fonctionnalité. Dès qu’une organisation ouvre Azure AI Foundry à ses lignes métier, des dizaines ou des centaines d’agents atterrissent dans M365 avec des permissions de connecteurs taillées sur mesure. Une EoP qui permet à un attaquant de republier ou de réorienter un agent hérite de toutes ces permissions d’un coup. Il n’y a aucun moyen simple de borner l’impact sans un inventaire de ce qui est publié et de ce que chaque agent peut atteindre.

Enfin, l’exploitation active avant patch redessine le calendrier. La fenêtre standard de divulgation à 90 jours ne s’applique pas quand le vendeur est lui-même la source de la divulgation et signale un abus dans la nature. La question défensive devient immédiate : partez du principe que la population d’agents de votre tenant a pu être touchée et agissez en conséquence.

Défenses

Les contrôles compensatoires publiés par Microsoft, complétés par ce que la divulgation impose à n’importe quel runtime d’agent, donnent une check-list serrée.

Inventoriez et délimitez d’abord. Cataloguez chaque workspace Azure AI Foundry et chaque agent M365 publié dans votre tenant. Pour chacun, notez le service principal, les connecteurs qu’il peut atteindre, les périmètres de données détenus par ces connecteurs, et qui est habilité à publier ou modifier l’agent. Vous ne pouvez pas raisonner sur le rayon de souffle sans cela.

Appliquez le moindre privilège aux service principals des agents. La plupart des agents publiés sont sur-permissionnés par défaut. Réduisez les connecteurs et les scopes Graph API au minimum strictement utilisé par l’agent. Retirez les accès permanents aux boîtes aux lettres, sites SharePoint et canaux Teams dont l’agent n’a pas besoin par design.

Imposez du conditional access sur le chemin de l’agent. Microsoft recommande des politiques de conditional access qui empêchent les agents d’opérer depuis des localisations non fiables, des appareils non fiables ou des sorties réseau anonymes. Traitez le service principal de l’agent comme un compte utilisateur du point de vue de ces politiques.

Désactivez ou mettez en quarantaine les agents les plus exposés. Les agents publiés exposés publiquement ou atteignables anonymement sont la priorité numéro un. Si vous ne pouvez pas immédiatement restreindre leur portée, retirez-les jusqu’à ce que le correctif du runtime arrive.

Déplacez les décisions d’identité côté serveur. C’est la leçon d’architecture qui survit au CVE spécifique. Tout framework d’agent qui laisse l’appelant déclarer qui il est — via un drapeau, un en-tête ou un token non lié — souffre du même mode de défaillance que senderIsOwner=true dans OpenClaw ou le contrôle d’appid trop lâche dans Azure SRE Agent. Liez le rôle, le tenant et la propriété à une session authentifiée validée côté serveur. Ne faites jamais confiance à la revendication de l’appelant.

Logguez, alertez, faites tourner les secrets. Mettez en place des alertes sur les modifications de configuration d’agent (republication, octroi de permissions, swap de connecteur), sur les schémas d’accès inhabituels des service principals d’agents, et sur les premiers appels vers des agents publiés sensibles. Après remédiation, faites tourner les secrets que chaque agent affecté avait le droit d’atteindre.

Statut

Élément	Détail
CVE	CVE-2026-35435
CWE	CWE-284 (Improper Access Control)
CVSS	8.6 (CRITIQUE)
Divulgation	7 mai 2026 (Microsoft, Patch Tuesday)
Éditeur	Microsoft
Produit affecté	Azure AI Foundry — agents M365 publiés
Statut du correctif	Pas de correctif au moment de la divulgation ; mitigations publiées
Exploitation	Active dans la nature selon Microsoft
Vecteur d’attaque	Réseau, sans interaction utilisateur
Mitigation principale	Moindre privilège sur les service principals d’agents, conditional access, quarantaine des agents les plus exposés