SSRF dans Azure OpenAI : quand un service d'IA managé devient un relais d'élévation de privilèges

De quoi s’agit-il ?

Le 2 juillet 2026, Microsoft a publié un avis de sécurité concernant une faille critique de type server-side request forgery (SSRF) dans Azure OpenAI, son service cloud d’exécution des modèles OpenAI (notamment la famille GPT) au sein de la plateforme Azure. La vulnérabilité a été notée 9.9 sur l’échelle CVSS 3.1 et classée comme une élévation de privilèges. Selon Microsoft et l’analyse du Patch Tuesday de juillet 2026 de CrowdStrike, la faille a été entièrement corrigée sur l’infrastructure de Microsoft : les clients du service n’ont aucun correctif à appliquer.

L’intérêt de cette découverte tient moins au risque immédiat — déjà corrigé côté serveur — qu’à ce qu’elle illustre : même une plateforme d’IA entièrement managée hérite des mêmes faiblesses de traitement des requêtes web qui affligent les applications cloud depuis dix ans. C’est une étude de cas défensive sur une classe de vulnérabilité, pas un exploit exploitable en l’état.

Comment ça marche

La server-side request forgery se produit lorsqu’un service peut être amené à effectuer des requêtes réseau vers des destinations choisies par l’attaquant. Dans un service d’IA managé, la surface de traitement des requêtes est particulièrement large : la plateforme va régulièrement chercher des URL fournies par l’utilisateur pour ingérer des documents destinés à la recherche, récupérer des images pour des prompts multimodaux ou rappeler des points d’accès d’outils et de fonctions. Chacun de ces chemins de code peut devenir un point d’aboutissement SSRF si la destination n’est pas strictement validée.

D’après la fiche NVD (CWE-918), la faille exigeait un attaquant authentifié et faiblement privilégié (PR:L), ne nécessitait aucune interaction utilisateur (UI:N), présentait une faible complexité d’attaque (AC:L) et — point décisif — un périmètre modifié (S:C). Ce changement de périmètre est ce qui a porté le score à 9.9 : le composant vulnérable pouvait agir sur des ressources au-delà de sa propre frontière de sécurité. Concrètement, une SSRF à l’intérieur d’un service cloud permet à un attaquant d’émettre des requêtes depuis le service vers des points d’accès internes non exposés sur Internet — API d’administration internes, services voisins, ou le point d’accès aux métadonnées d’instance qui délivre des jetons d’identité. Atteindre ces surfaces internes depuis une position de confiance, c’est ainsi qu’une faille de falsification de requête se transforme en élévation de privilèges. Aucune preuve de concept publique n’a été diffusée, et Microsoft n’a pas détaillé le point d’injection exact.

Pourquoi c’est important

Les entreprises traitent de plus en plus les points d’accès d’IA managés comme une infrastructure de confiance placée au cœur de leur réseau, connectée à des dépôts de données privés via des identités managées. Cette confiance est précisément le problème. Lorsque le service d’IA lui-même peut être orienté pour émettre des requêtes internes, sa position réseau et l’identité qui lui est assignée deviennent celles de l’attaquant, non les vôtres. Le rayon d’impact d’une SSRF se mesure à tout ce que le service compromis a le droit d’atteindre.

Ce cas rappelle que la ligne de « responsabilité partagée » se déplace mais ne disparaît jamais. Microsoft possédait cette vulnérabilité précise et l’a corrigée. Mais la leçon d’architecture — la capacité d’un service d’IA à émettre des requêtes sortantes est une surface d’attaque à part entière — s’applique à chaque serveur d’inférence auto-hébergé, passerelle et pipeline d’ingestion RAG que vous exploitez vous-même, où aucun fournisseur ne viendra corriger la faille en silence.

Défenses

Un durcissement concret et non intrusif pour quiconque exploite des services d’IA qui vont chercher du contenu externe :

• Verrouillez les flux sortants. Les composants d’ingestion et d’appel d’outils ne devraient atteindre qu’une liste blanche explicite de destinations. Appliquez un refus par défaut du trafic sortant et bloquez au niveau réseau les plages privées (RFC 1918), les adresses link-local et le point d’accès aux métadonnées (169.254.169.254).
• Protégez les métadonnées d’instance. Imposez des jetons liés à une session de type IMDSv2 (ou l’équivalent durci de votre cloud) afin qu’une simple SSRF ne puisse pas extraire des identifiants d’identité.
• Réduisez les identités managées au moindre privilège. Accordez à chaque charge d’IA le rôle et le périmètre de ressources les plus étroits possibles ; une identité volée n’est dangereuse qu’à hauteur de ses permissions.
• Validez et re-résolvez les URL. Rejetez les schémas non-HTTP, canonicalisez puis re-résolvez les noms d’hôtes après validation pour déjouer le DNS-rebinding, et ne suivez jamais de redirection vers l’espace interne.
• Isolation des tenants et supervision. Segmentez les chemins réseau par tenant et journalisez les requêtes sortantes du service ; une destination interne anormale est un indicateur SSRF à fort signal.

Appliquer ces contrôles fait qu’une SSRF dans votre propre pile échoue en mode fermé au lieu de devenir un point de pivot vers votre plan de contrôle cloud.

Statut

Élément	Détail
Produit affecté	Azure OpenAI (service cloud managé)
Classe de faiblesse	Server-side request forgery (CWE-918)
Sévérité	Score de base CVSS 3.1 : 9.9 (Critique) — vecteur AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Divulgation	2 juillet 2026 (avis Microsoft / NVD)
Correctif	Corrigé entièrement sur l’infrastructure Microsoft ; aucune action client requise
Exploit public	Aucun connu à ce jour
Référence	CVE-2026-45499