Menu

Azure SRE Agent : un flux OBO cassé transforme l’agent en passe-partout sur toute votre infra

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
2 min de lecture

CVSS 9.9, corrigée dans le Patch Tuesday d’août 2026 : un attaquant peu privilégié pouvait hériter des permissions complètes de l’identité managée d’Azure SRE Agent, l’agent qui a le droit de toucher vos runbooks et votre infra de production en autonomie.

Source : Microsoft Security Response Center, CVE-2026-62830, corrigée le 11 août 2026 (Patch Tuesday) ; analyse relayée par Forkast, 7 août 2026.

Le CVE qui change de catégorie

Je regarde les Patch Tuesday depuis des années comme une routine : on trie, on priorise le patching sur les CVE exploitées, on avance. CVE-2026-62830 sort de cette routine, parce qu’elle ne parle pas d’un logiciel qu’on corrige et qu’on oublie ; elle parle d’un agent IA à qui on a donné une identité, et dont la faille brise la frontière censée contenir cette identité.

Azure SRE Agent surveille, diagnostique et remédie de façon autonome sur l’infrastructure Azure qu’on lui confie. Pour agir, il porte une identité managée avec ses propres permissions. CVE-2026-62830 est une faille de type CWE-862 (missing authorization) dans le flux on-behalf-of (OBO) de l’agent : un attaquant peu privilégié, sans interaction utilisateur, à faible complexité d’attaque, pouvait élever ses privilèges via le réseau et hériter des permissions de ce service principal ; pas seulement sur l’agent, mais sur tout ce que son identité managée pouvait toucher.

Note du PandaRedacteur : “l’agent a une frontière de sécurité” est une phrase qui tient jusqu’à ce qu’on découvre que le flux censé la faire respecter n’authentifie pas vraiment qui parle en son nom.

Le vecteur est classé “Scope Changed” dans le CVSS : ce n’est pas l’agent seul qui est compromis, c’est tout le rayon d’action de son identité (runbooks, télémétrie, ressources Azure gérées) qui devient accessible à l’attaquant.

Microsoft a corrigé la faille côté service, sans action requise côté client. Mais un correctif serveur ne dit rien de ce que l’attaquant aurait pu faire pendant la fenêtre d’exposition, ni de la question qui reste ouverte pour tout le monde : combien de vos agents portent aujourd’hui une identité dont personne n’a vraiment audité la portée réelle ?

Je détaille dans la version complète l’analyse STRIDE, l’impact sur le blast radius d’un agent SRE compromis, et en contenu premium une checklist d’audit des identités managées d’agents IA sur Azure, un script d’inventaire des attributions de rôles, ainsi que les principes de conception à appliquer en amont pour ne pas avoir à faire cet audit dans l’urgence la prochaine fois.

🔒 Analyse complète en contenu premium
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite à me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
LinkedIn Reddit Substack