OpenAI a corrigé une faille SSRF de gravité élevée dans la fonctionnalité des GPT personnalisés de ChatGPT après qu’un chercheur a démontré qu’elle pouvait exposer des métadonnées internes du cloud et potentiellement des identifiants Azure.
Le problème souligne les inquiétudes croissantes concernant la façon dont les URL contrôlées par les utilisateurs dans les systèmes d’IA peuvent introduire des vulnérabilités web traditionnelles dans des environnements avancés pilotés par l’IA.
Comment les redirections et les en-têtes ont permis l’exploitation de la faille SSRF
Les vulnérabilités SSRF surviennent lorsque des applications récupèrent des ressources à partir d’URL fournies par les utilisateurs sans validation appropriée, permettant aux attaquants de contraindre les systèmes à effectuer des requêtes internes non autorisées.
Dans les environnements cloud, les enjeux sont particulièrement importants, car les points de terminaison de métadonnées contiennent souvent des informations sur l’instance et des jetons d’accès temporaires.
L’abus de ces points de terminaison peut entraîner des compromissions du cloud chez plusieurs fournisseurs.
Les GPT personnalisés, une fonctionnalité premium de ChatGPT, permettent aux utilisateurs d’intégrer des API externes à l’aide de schémas OpenAPI.
Ces « Actions » permettent aux GPT de récupérer des informations en temps réel — comme des données météorologiques — via des requêtes HTTP externes.
En explorant l’interface, le chercheur a remarqué que le système autorisait des URL d’API arbitraires ainsi que des en-têtes d’authentification configurables.
Un bouton « Test » intégré exécutait ces requêtes directement depuis l’infrastructure d’OpenAI, suscitant immédiatement des inquiétudes quant à une exposition à la SSRF.
Dans un premier temps, une tentative d’exploitation a échoué, car le système exigeait des URL HTTPS tandis que l’Instance Metadata Service (IMDS) d’Azure utilise le protocole HTTP non chiffré.
Cependant, le chercheur a contourné cette restriction en redirigeant un point de terminaison HTTPS vers l’URL de l’IMDS au moyen d’une redirection 302 depuis un domaine externe.
Les serveurs d’OpenAI ont suivi la redirection, mais l’accès leur a tout de même été refusé, car Azure exige l’en-tête spécial Metadata: true.
Comment le chercheur a exploité la faille SSRF
Le déclic est survenu lorsque le chercheur a compris que l’interface des GPT personnalisés autorisait des en-têtes de clés d’API arbitraires.
En nommant l’un d’eux « Metadata » et en lui attribuant la valeur « true », la requête a injecté avec succès l’en-tête nécessaire.
Grâce à la combinaison correcte de la redirection et de l’en-tête, le chercheur a récupéré les métadonnées de l’IMDS, notamment un jeton OAuth2 valide pour l’API de gestion d’Azure.
Ce jeton, émis automatiquement par l’identité managée attribuée à l’environnement de calcul, permettait d’accéder à des ressources cloud sensibles.
Les métadonnées exposées comprenaient des jetons Azure privilégiés capables d’interagir avec l’empreinte cloud d’OpenAI.
Bien que le chercheur ait indiqué qu’il ne s’agissait pas de la faille la plus grave qu’il avait découverte, le potentiel de déplacement latéral et d’énumération des ressources cloud rendait le problème extrêmement dangereux.
Renforcer les plateformes d’IA contre les menaces SSRF
OpenAI ayant publié un correctif pour la récente vulnérabilité SSRF, les entreprises devraient néanmoins mettre en place des mesures de protection supplémentaires contre les risques similaires, notamment :
- Imposer des listes d’autorisation strictes pour les connexions sortantes : Restreindre le trafic côté serveur afin que les applications ne puissent communiquer qu’avec des services externes approuvés.
- Bloquer par défaut les points de terminaison de métadonnées du cloud : Désactiver l’accès à l’IMDS lorsque cela est possible, ou exiger IMDSv2/des requêtes autorisées afin de réduire les risques d’exposition accidentelle.
- Utiliser des contrôles d’egress réseau : Mettre en place des règles de pare-feu et des groupes de sécurité de réseau virtuel pour empêcher les requêtes internes ou externes involontaires.
- Appliquer une validation zero trust pour les requêtes pilotées par l’IA : Traiter toute activité réseau générée ou déclenchée par l’IA comme non fiable jusqu’à sa vérification complète.
- Mettre en place des limites robustes de gestion des identités et des accès (IAM) : Limiter les privilèges associés aux rôles de calcul cloud afin de réduire l’ampleur d’une compromission de jetons.
- Surveiller le trafic sortant anormal : Utiliser l’analyse comportementale pour détecter les appels inhabituels aux métadonnées internes, les chaînes de redirection ou les tentatives d’accès échouées répétées.
- Examiner les intégrations tierces dans les workflows d’IA : S’assurer que les schémas d’API, les URL fournies par les utilisateurs et les actions d’IA personnalisées sont isolés dans un bac à sable et validés.
Alors que les systèmes d’IA s’intègrent toujours plus profondément aux workflows métier critiques, la sécurisation de leur comportement réseau devient essentielle pour préserver la confiance et la résilience.
La découverte de cette faille SSRF montre comment des problèmes de sécurité web traditionnels peuvent réapparaître de manière inattendue à mesure que les plateformes d’IA gagnent en complexité et en interconnexion.
Même si OpenAI a réagi rapidement en publiant un correctif, l’incident souligne l’importance d’une sécurité en profondeur.
Les entreprises devraient renforcer les contrôles fondés sur l’identité et mettre en place une vérification continue à l’aide de solutions zero trust.