Check Point Research a documenté une défaillance d'isolation entre comptes dans l'environnement d'exécution de code de ChatGPT. Elle pouvait transformer une conversation ordinaire en canal de tâches caché. Dans la preuve de concept des chercheurs, la session d'une victime a récupéré des données dans un compte Gmail connecté et les a transmises à un autre compte ChatGPT, tandis que la réponse visible semblait normale.
Le résultat a été publié le 8 septembre 2026. Son intérêt tient au mécanisme précis: le modèle n'avait besoin ni d'un accès direct à Internet, ni d'identifiants volés, ni d'une évasion classique du conteneur. Des conteneurs d'exécution distincts pouvaient atteindre le même service interne de paquets. Les métadonnées modifiables de ce service n'étaient pas isolées par compte et pouvaient donc transporter des instructions et des résultats entre sessions.
Le chemin concerné n'est plus disponible. Check Point indique que le canal avait déjà disparu à la fin de son rapport. OpenAI a confirmé, selon les chercheurs, que l'instance Artifactory interne identifiée avait été mise hors service. La publication ne démontre ni une exploitation généralisée ni l'existence de clients touchés. Elle décrit une recherche contrôlée menée en juin et une preuve de concept concrète.
Fonctionnement du canal caché
ChatGPT créait des conteneurs isolés pour les tâches nécessitant l'exécution de code. Selon Check Point, ces conteneurs ne pouvaient pas communiquer directement entre eux ni accéder à Internet. Ils pouvaient toutefois utiliser un même service interne JFrog Artifactory pour récupérer des paquets logiciels.
La récupération des paquets n'était pas le problème. Le service exposait des opérations permettant à un conteneur d'ajouter des propriétés à un élément de dépôt et de les relire. Les identifiants disponibles dans le conteneur autorisaient ces deux opérations. Check Point a écrit une valeur de test depuis un compte, puis a retrouvé cette valeur depuis un autre. Des données plus volumineuses pouvaient être réparties dans plusieurs propriétés avant d'être réassemblées.
Ce comportement formait une sorte de presse-papiers partagé. Un attaquant pouvait y placer une instruction cachée. Une requête malveillante, une conversation partagée ou un GPT personnalisé pouvait demander à la session de la victime de consulter ce canal lors d'un échange ultérieur. La demande visible recevait toujours une réponse ordinaire, pendant qu'une seconde tâche utilisait les outils et les autorisations de la session de la victime.
La démonstration avec Gmail explique pourquoi une lecture peut avoir de lourdes conséquences. Check Point indique que la victime voyait un petit avis signalant l'utilisation de Gmail, mais cet avis apparaissait après l'accès et ne révélait ni la demande cachée ni les données renvoyées. La preuve relie ainsi trois frontières souvent examinées séparément: l'isolation des locataires, la confiance accordée aux instructions et l'autorisation des applications connectées.
Ce que les preuves montrent réellement
Les preuves techniques primaires viennent du chercheur en sécurité et non d'un rapport public d'incident publié par OpenAI. TechRadar et The Register corroborent le mécanisme décrit, la démonstration Gmail et la fermeture du canal identifié. Leurs détails techniques restent toutefois fondés sur les travaux de Check Point.
La recherche prouve que le chemin fonctionnait dans l'environnement testé. Elle ne montre pas qu'un attaquant l'a utilisé contre des clients. Elle ne prouve pas non plus que toutes les fonctions de ChatGPT, tous les types de comptes ou toutes les applications connectées étaient exposés. L'impact dépendait des outils, des données et des autorisations disponibles dans la session de la victime.
Cette distinction est essentielle pour la réponse aux incidents. Une équipe ne doit pas considérer chaque ancienne lecture Gmail ou chaque conversation partagée comme une compromission. Elle peut utiliser ce rapport pour rechercher un état interne partagé, des identifiants d'exécution trop puissants ou des lectures sans limite d'autorisation adaptée dans ses propres plateformes d'agents.
La leçon de contrôle dépasse le service partagé
L'isolation des conteneurs n'est qu'une couche du modèle de sécurité d'un agent. Toute API interne, tout cache, proxy de paquets, magasin de métadonnées ou interface d'administration accessible depuis l'environnement d'exécution doit figurer dans le modèle de menace. Si un locataire peut modifier un état qu'un autre peut lire, le service devient un canal caché même lorsque l'isolation réseau fonctionne comme prévu.
Les applications connectées amplifient la conséquence possible. Un environnement capable de lire des courriels, du code source, des fichiers ou des données collaboratives doit recevoir uniquement les droits nécessaires à la tâche actuelle. Une lecture sensible doit être évaluée selon le type de données, le demandeur, le but et la destination. Elle ne devient pas peu risquée simplement parce qu'elle ne modifie aucun enregistrement externe.
La provenance des instructions compte aussi. Un texte hérité d'une conversation partagée, d'une configuration d'agent, d'un document récupéré ou d'un message externe ne doit pas recevoir automatiquement la même autorité que la demande actuelle de l'utilisateur. La plateforme doit séparer les instructions fiables du contenu non fiable et empêcher un texte caché d'élargir silencieusement la portée de la tâche.
Les équipes peuvent tester ces frontières avec le bac à sable Maetra Secure. Le guide des journaux d'audit IA aide à relier requêtes, appels d'outils, accès aux données et résultats sans collecter de contenu inutile.
Questions pour une revue d'entreprise
Les équipes de sécurité et de plateforme devraient inventorier chaque service partagé accessible à un agent. Elles doivent identifier les valeurs qui peuvent être écrites ou lues entre sessions. Les identifiants d'exécution doivent être contrôlés pour trouver les droits qui dépassent la récupération de paquets, notamment les opérations sur les métadonnées et les interfaces de gestion.
Les lectures par les applications connectées nécessitent aussi une revue propre. L'utilisateur voit-il la ressource avant l'accès? L'autorisation est-elle liée à la tâche et à l'identité actuelles? Une instruction cachée ou héritée peut-elle déclencher la lecture? Les journaux conservent-ils la source de l'instruction, l'appel d'outil, la catégorie des données renvoyées et leur destination?
Enfin, il faut tester le chemin complet de défaillance. L'équipe doit pouvoir isoler une session, révoquer ou renouveler les identifiants, rechercher des marqueurs inattendus entre sessions et distinguer, dans une enquête, une tentative bloquée d'un accès aux données réellement exécuté.
Analyse Maetra
La principale leçon de gouvernance est que l'autorisation doit suivre tout le chemin de l'action. Un bac à sable réseau peut fonctionner correctement tandis qu'un état partagé ouvre un autre passage. Un droit d'outil peut être valide pour l'utilisateur alors que l'instruction qui l'invoque vient d'une source non autorisée.
L'unité de contrôle pratique n'est donc pas seulement le conteneur ou le connecteur. Elle combine locataire, session, source de l'instruction, outil, ressource, but et destination. L'enregistrement et l'application de cette enveloppe rendent l'exécution cachée plus difficile et fournissent des preuves utiles lorsqu'une frontière échoue.
Ce rapport justifie de retester les infrastructures partagées et les droits des applications connectées. Il ne prouve pas que le canal fermé reste exploitable ni que des comptes clients ont été largement compromis.