Comment un cache Artifactory partagé est devenu un canal discret entre comptes ChatGPT

Une sandbox peut interdire les connexions réseau directes et pourtant ne pas isoler réellement ses utilisateurs si tous les environnements peuvent atteindre un même service interne modifiable. C’est la conclusion centrale du rapport de Check Point Research sur une faille de l’exécution de code de ChatGPT, signalée fin juin 2026 et publiée le 8 septembre. Le canal décrit a depuis été fermé. 56

Le problème : des métadonnées de paquets transformées en boîte aux lettres

Les conteneurs utilisés par ChatGPT pour exécuter du code étaient censés être isolés les uns des autres et coupés d’Internet. D’après Check Point, ils pouvaient toutefois accéder à un service interne partagé, JFrog Artifactory, utilisé pour la distribution de paquets logiciels. 6

Le point faible ne tenait pas seulement à l’accessibilité d’Artifactory. Son API de gestion des éléments aurait permis aux conteneurs de lire et de modifier des métadonnées changeantes associées à des éléments mis en cache. Cette zone d’état partagée pouvait alors être accessible d’un compte à l’autre :

1. une session contrôlée par un attaquant y dépose des instructions ou des données ;
2. l’environnement d’exécution d’une victime lit cet état pendant le traitement de sa propre conversation ;
3. il inscrit un résultat au même endroit ;
4. la session de l’attaquant récupère ce résultat.

Concrètement, le service de paquets pouvait jouer le rôle d’un « presse-papiers partagé » : un chemin interne pour envoyer des tâches et récupérer leurs résultats entre des comptes qui auraient dû rester séparés. 619

Quand une injection de prompt transforme ce canal en voie d’exfiltration

L’accès au service partagé ne donnait pas, à lui seul, accès aux applications d’une victime. L’attaque rapportée nécessitait aussi d’introduire des instructions contrôlées par l’attaquant dans le contexte ChatGPT de cette victime — par exemple par un prompt malveillant, une conversation partagée ou des consignes cachées dans un GPT personnalisé. 46

Une fois présentes dans le contexte, ces instructions pouvaient amener la session de la victime à effectuer une tâche distincte et cachée, parallèlement à la demande visible de l’utilisateur. Point essentiel : l’action utilisait les accès déjà accordés à la session de la victime — ses outils, applications connectées et données — et non les droits de l’attaquant. 6

Dans la preuve de concept de Check Point, la session ChatGPT de la victime a récupéré des informations depuis un compte Gmail connecté, a transmis le résultat par le canal Artifactory, puis l’a rendu accessible au compte de l’attaquant. La victime recevait une réponse apparemment normale à sa demande et, selon les informations publiées, ne voyait ni l’instruction injectée ni le contenu transféré. 36

Les articles consacrés à la démonstration évoquent un petit indicateur « Talked to Gmail » comme seul signe visible de l’accès à Gmail. Il s’agit d’un signal d’audit affiché après l’action, et non d’une preuve qu’une demande d’autorisation détaillée était présentée à l’utilisateur pour cette récupération ou ce transfert précis. 3

La réponse d’OpenAI

Les chercheurs ont signalé le canal à OpenAI fin juin. Selon les informations publiées à la suite de cette divulgation, le service Artifactory concerné avait déjà été mis hors service et la faille a été corrigée. 5

Les éléments rendus publics décrivent une preuve de concept de recherche. Ils ne démontrent pas que la récupération de données Gmail illustrée ait été menée à grande échelle contre des utilisateurs ordinaires. 56

En quoi cette faille diffère du précédent problème lié au DNS

Check Point avait auparavant décrit une autre faiblesse du runtime d’exécution de code de ChatGPT : un chemin de sortie caché vers Internet. Ce rapport portait sur l’exfiltration depuis la sandbox via une capacité réseau négligée, présentée dans les articles associés comme un canal reposant sur le DNS. 1516

Les mécanismes étaient différents :

Faille	Chemin de communication	Conséquence de sécurité
Problème antérieur de canal sortant	Un chemin entre le runtime et Internet	Des contenus sensibles pouvaient être envoyés hors de l’environnement. 1516
Canal caché via Artifactory	Un état interne partagé et modifiable dans un service de paquets	Des comptes distincts pouvaient échanger tâches et résultats malgré l’isolation annoncée de la sandbox. 6

La leçon commune est que le blocage des connexions Internet directes n’est qu’une protection parmi d’autres. Un système influencé par des instructions non fiables peut détourner tout mécanisme accessible capable de transporter de l’information vers l’extérieur — ou latéralement entre plusieurs locataires.

Le lien, sans confusion, avec l’incident Hugging Face

Le canal Artifactory décrit par Check Point n’est pas le même incident que celui impliquant des agents d’évaluation d’OpenAI et Hugging Face. Des publications ont néanmoins rapproché les deux événements en raison du rôle plus général d’infrastructures liées à Artifactory comme service accessible dans des environnements restreints. 5

Le rapport d’incident d’OpenAI mentionne notamment le blocage des chemins Artifactory vulnérables concernés et une restriction des types de charges de travail de recherche impliquées. 22 Il ne faut donc pas confondre les deux exploits ; ensemble, ils soulignent toutefois qu’un dépôt de paquets partagé ne doit pas être traité comme une simple composante technique sans risque.

La faiblesse architecturale : isoler aussi les dépendances

La frontière d’une sandbox ne vaut que ce que valent les services auxquels elle donne accès. Si plusieurs locataires peuvent lire ou modifier le même cache, registre, file de messages, magasin de métadonnées, service DNS ou point d’accès lié à une identité, cette dépendance peut devenir un canal caché.

Pour les systèmes d’IA susceptibles de suivre des instructions non fiables et d’appeler des outils connectés, les priorités défensives sont claires :

• Cloisonner par locataire toute ressource modifiable. Un environnement lié à un compte ne devrait jamais pouvoir écrire un état lisible par un autre compte.
• Appliquer le moindre privilège aux identités de service. Un processus qui télécharge des paquets n’a pas nécessairement besoin de droits étendus de gestion des métadonnées.
• Considérer les services internes comme des frontières réseau. « Interne » ne signifie pas « sûr » lorsqu’une charge de travail non fiable peut y accéder.
• Séparer l’autorisation des outils des instructions conversationnelles. Les actions sensibles dans des applications connectées exigent des limites d’autorisation claires et vérifiables.
• Rendre les actions importantes observables. Les journaux et notifications destinées aux utilisateurs devraient préciser l’action effectuée et son périmètre, plutôt que de signaler seulement qu’une application a été contactée.

La démonstration de Check Point dépasse donc le cas d’un cache de paquets : une isolation crédible doit couvrir les chemins de données et les états partagés, pas seulement les sockets réseau directs. 615