Selon les chercheurs, une lacune d’authentification multi-tenant dans l’agent d’opérations IA de Microsoft a exposé les flux de commandes en direct, le raisonnement interne et les informations d’identification de tout compte Entra ID.
Une faille d’authentification de haute gravité dans l’agent Azure SRE de Microsoft a exposé les données sensibles de l’agent à un accès réseau non autorisé, selon une divulgation de vulnérabilité confirmée.
Le problème a été identifié par Yanir Tsarimi, chercheur chez Enclave AI, qui a détaillé les résultats dans un article de blog décrivant comment accéder aux interactions des agents sans contrôles d’authentification appropriés. La vulnérabilité a été suivie comme CVE-2026-32173 et classée critique avec un score CVSS de 8,6.
Dans le blog, Tsarimi décrit des scénarios dans lesquels l’activité des agents pourrait être observée pendant l’exécution, y compris les interactions entre les utilisateurs et le système. L’exposition provenait d’une lacune d’authentification dans le service, permettant l’accès aux flux de données sans informations d’identification valides.
Microsoft l’a classé comme un problème d’authentification inapproprié qui permet à un attaquant non autorisé de divulguer des informations sur un réseau, indique l’entrée NVD.
« Imaginez que vous embauchiez un assistant qui a accès à tout : vos serveurs, vos journaux, vos mots de passe, votre code source. Imaginez maintenant qu’un parfait inconnu, issu d’une entreprise totalement indépendante, puisse écouter silencieusement chaque conversation de cet assistant », a écrit Yanir Tsarimi, chercheur chez Enclave. « C’est ce que nous avons trouvé dans Azure SRE Agent. »
Microsoft a depuis résolu le problème, ajoute le blog. Le correctif a été appliqué côté serveur et l’avis de Microsoft indique qu’aucune action du client n’est requise. L’agent Azure SRE a atteint la disponibilité générale le 10 mars.
Multi-tenant par défaut
L’agent diffuse toutes les activités via un point de terminaison WebSocket appelé /agentHub, indique le blog.
Le point de terminaison nécessitait un jeton pour se connecter, mais l’enregistrement de l’application Entra ID sous-jacente était configuré comme multi-locataire, ce qui signifie que n’importe quel compte de n’importe quel locataire Entra ID pouvait obtenir un jeton valide que le hub accepterait.
« Le hub a ensuite vérifié : le jeton est-il valide ? Oui. L’audience est-elle correcte ? Oui. Il n’a jamais demandé : cet appelant appartient-il au locataire de la cible ? Sont-ils autorisés à utiliser cet agent ? Ont-ils un rôle sur cette ressource ? » Tsarimi a écrit.
Une fois connecté, le hub diffuse tous les événements à tous les clients sans filtrage d’identité, indique le blog.
Le canal exposé comprenait les invites utilisateur, les réponses des agents, les traces de raisonnement internes, chaque commande exécutée avec des arguments complets et le résultat de la commande.
« Dans notre propre environnement de test, nous avons observé l’agent exécuter une tâche de routine et renvoyer les informations d’identification de déploiement pour les applications Web en direct », a écrit Tsarimi. « Un espion sur une cible réelle aurait reçu la même chose. Silencieusement. Sans rien indiquer que quelqu’un d’autre était en ligne. »
L’exploitation nécessitait uniquement le sous-domaine de l’agent cible, qu’Enclave a décrit comme prévisible et dénombrable, et environ 15 lignes de Python. Les trackers tiers ont identifié le composant concerné comme étant Azure SRE Agent Gateway SignalR Hub.
Regarder un opérateur privilégié penser à voix haute
Cette catégorie de faille ne doit pas être comparée de trop près à un bug d’API classique, a déclaré Alexander Hagenah, chercheur en cybersécurité et directeur exécutif de l’opérateur d’infrastructure financière basé à Zurich, SIX Group.
« Un problème d’API normal est généralement lié à un point de terminaison, un ensemble de données ou une vérification d’autorisation spécifique. Avec un agent d’opérations IA, l’agent lui-même devient le point d’agrégation de l’état de l’infrastructure, des journaux, du code source, du contexte de l’incident, des commandes, des sorties et parfois des informations d’identification qui apparaissent lors du dépannage », a déclaré Hagenah.
« Concrètement, cela peut ressembler à un opérateur privilégié qui pense à voix haute », a-t-il ajouté.
L’exposition ne constitue pas une compromission automatique de l’infrastructure, a déclaré Hagenah, mais elle peut être plus précieuse que de nombreux bogues en lecture seule. Les attaquants doivent généralement travailler dur après l’accès initial pour comprendre un environnement. Un agent SRE peut déjà avoir ce contexte assemblé pour lui.
La connexion n’a également laissé aucune trace du côté de la victime, écrit le chercheur. « Les organisations de victimes n’avaient aucun moyen de le détecter, aucun moyen d’enquêter après coup, et aucun moyen d’évaluer ce qui avait été révélé. »
Considérations pour les entreprises
Enclave, selon l’article de blog, a noté que les organisations qui ont exécuté l’agent Azure SRE pendant la fenêtre d’aperçu doivent traiter la période comme potentiellement exposée et examiner toutes les informations d’identification, données de configuration ou informations sensibles pouvant avoir transité via les conversations de l’agent ou les sorties CLI.
Hagenah a déclaré que les services d’opérations agentiques doivent être régis davantage comme des plates-formes d’automatisation privilégiées que comme des outils SaaS ordinaires.
« Avant d’accorder ce niveau d’accès, je voudrais des réponses très claires sur l’isolation des locataires et l’autorisation au niveau des ressources. Il ne devrait pas suffire qu’un jeton soit valide. Le service doit vérifier que l’appelant appartient au bon locataire, est autorisé pour cet agent spécifique et est autorisé à accéder à ce flux, thread, sortie d’outil ou action spécifique », a-t-il déclaré.
L’agent doit fonctionner sous une identité gérée dédiée avec des autorisations minimales, et les intégrations avec l’exécution de commandes, les requêtes de journaux, les référentiels sources et les plates-formes d’incidents doivent être revues comme tout autre système privilégié, a déclaré Hagenah. Les entreprises doivent également savoir qui s’est connecté, à quels threads ils ont accédé, quelles commandes ont été exécutées et quelle sortie a été renvoyée, avec des journaux exportables vers le SIEM. Microsoft n’a pas immédiatement répondu à une demande de commentaire.
