Azure SRE Agent : un contrôle de token multi-tenant qui laissait des inconnus écouter vos incidents (CVE-2026-32173)

De quoi parle-t-on ?

Le 20 avril 2026, Yanir Tsarimi (Enclave AI) a publié How We Could Watch Your Azure SRE Agent In Real Time, le compte-rendu public de CVE-2026-32173 — une faille de divulgation d’information dans Azure SRE Agent de Microsoft. La CVE a été initialement publiée le 2 avril 2026, score CVSS de 8.6, classification CWE-287 (Improper Authentication). Le Microsoft Security Response Center a confirmé, qualifié la faille de critique, et déployé un correctif côté serveur ; aucune action n’est requise des clients qui adoptent le produit en GA.

La vulnérabilité se situe à l’intersection de deux choix d’ingénierie bien connus : un hub SignalR sur WebSocket pour diffuser l’activité d’un agent IA, et une app registration Entra ID configurée en multi-tenant. Chacun, pris isolément, est sain. Combinés sans la vérification de tenant manquante, ils ont exposé à une écoute silencieuse inter-tenants chaque Azure SRE Agent actif jusqu’au correctif Microsoft.

Mécanique de la faille

Azure SRE Agent est passé en disponibilité générale le 10 mars 2026. C’est l’agent d’exploitation toujours-actif de Microsoft : connecté à un environnement Azure, il surveille les alertes, diagnostique les incidents, exécute des commandes Azure CLI, redémarre des services, et s’intègre à PagerDuty et ServiceNow. Pour rendre tout cela lisible aux humains, l’agent diffuse chaque événement — prompts utilisateur, réponses du modèle, traces de raisonnement interne, appels d’outils avec arguments, sorties d’outils — via un endpoint WebSocket nommé /agentHub, hébergé sur l’Azure SRE Agent Gateway sous forme de SignalR Hub.

Le hub filtrait les connexions entrantes via un token bearer. La logique de validation contrôlait la signature et l’audience, deux éléments que n’importe quel compte Entra ID, dans n’importe quel tenant, peut produire face à une app registration multi-tenant. Deux contrôles étaient absents :

# Ce que le hub validait (schéma — illustratif, pas du code d'exploit)
token_signature_valid   # ✅
audience_matches_app    # ✅

# Ce qu'il ne validait pas
caller_tenant == target_agent_tenant   # ❌
caller_has_role_on_resource            # ❌

Une fois la connexion établie en WebSocket, le hub ne filtrait pas les événements par identité de l’appelant. Il diffusait chaque événement à chaque client connecté. Rejoindre le flux d’une cible ne demandait que le sous-domaine de son agent — qualifié par Enclave de prédictible et énumérable — et environ 15 lignes de Python pour obtenir un token auprès de login.microsoftonline.com et se connecter au SignalR hub.

La transcription visible de l’autre côté incluait les prompts de l’utilisateur, les réponses de l’agent, la chaîne de raisonnement privée de l’agent, chaque invocation CLI avec ses arguments complets, et la sortie de commande. Dans le test mené par Enclave, cette sortie contenait des identifiants de déploiement pour des applications web en production. L’attaque ne laissait aucune trace côté tenant victime ; le seul enregistrement existait dans le terminal de l’attaquant.

Pourquoi c’est important

Trois leçons portent plus loin que la CVE elle-même.

La première est structurelle. Un hub SignalR adossé à Entra ID n’est pas exotique. L’erreur reproduit ici le même schéma de confusion d’autorisation qui touche les SaaS multi-tenant depuis une décennie — token valide ≠ utilisateur autorisé — appliqué à un flux d’une valeur inhabituellement élevée. Toute équipe qui rattache un canal temps réel à un agent IA hérite de cette surface de risque.

La deuxième est l’observabilité. Les agents IA agrègent par construction un état normalement fragmenté entre endpoints : tickets, dashboards, secret stores, pipelines de déploiement, traces de raisonnement. Quand un seul canal expose cette agrégation, le rayon d’impact devient tout ce que l’agent a touché, synthétisé pour l’attaquant. Une fuite d’API ordinaire perd les données d’un endpoint. Une fuite d’agent perd la vision du monde du modèle.

La troisième est l’absence de télémétrie côté victime. Les tenants n’avaient ni logs pour cadrer le périmètre d’exposition, ni signaux pour enquêter a posteriori. Pour les agents IA en production opérationnelle, la télémétrie sur qui consomme le flux n’est plus négociable.

Défenses

Mesures concrètes qui découlent de cette divulgation.

Si vous avez exécuté Azure SRE Agent pendant la fenêtre de préversion (entre le 10 mars et le correctif côté serveur), traitez cette période comme potentiellement exposée : rotation des identifiants et secrets susceptibles d’avoir transité dans les transcriptions ou les sorties CLI de l’agent, et revue des données de configuration auxquelles l’agent avait accès.

Pour tout agent maison qui diffuse son activité par WebSocket/SignalR/SSE, validez l’appartenance au tenant ET l’autorisation sur le hub lui-même, pas seulement la signature du bearer. Traitez la claim tid et l’ACL de la ressource comme des contrôles obligatoires avant d’abonner un client à un groupe. Marquez les app registrations en single-tenant sauf si le multi-tenant est une exigence produit délibérée — et lorsque c’est le cas, écrivez la logique d’isolation explicitement.

Pour SignalR spécifiquement, utilisez des groupes clés sur l’ID de tenant ou de ressource et ajoutez un filtre d’autorisation dans OnConnectedAsync. Refusez toute connexion dont les claims n’incluent pas un rôle sur la ressource cible. Traitez le hub comme n’importe quelle autre surface d’API dans votre modèle de menace.

Faites des transcriptions d’agent IA une surface auditable de première classe. Émettez des événements par abonné dans votre log de sécurité, exposez-les au tenant client, et alertez sur les abonnés inattendus. Le fait que les victimes d’Azure SRE Agent n’aient pas pu voir les écoutants est le défaut qui a transformé un bug d’autorisation en incident furtif.

Enfin, modélisez les agents comme canaux de transit d’identifiants. Si l’agent peut lire des secrets pour faire son travail, chaque canal qui expose sa trace est un canal de gestion de secrets et doit être classifié comme tel.

Statut

Élément	Détail
CVE	CVE-2026-32173
CVSS	8.6 (HIGH)
CWE	CWE-287 (Improper Authentication)
Publication (NVD)	2 avril 2026
Compte-rendu public	20 avril 2026 (Enclave AI)
Composant affecté	Azure SRE Agent Gateway, SignalR Hub /agentHub
Date GA du produit	10 mars 2026
Correctif	Côté serveur, déployé par Microsoft. Aucune action client requise.
Auteur du signalement	Yanir Tsarimi, Enclave AI