ChatGPT : une faille permettait de voler les données d’un compte

Les aperçus HTML de ChatGPT sont censés s’afficher dans un cadre isolé du reste du compte. Des chercheurs de Parameter Labs décrivent comment ils ont contourné cet isolement. Au bout de leur chaîne d’attaque : les données privées d’un utilisateur connecté, ou des actions menées en son nom.

L’analyse est relayée par le développeur Simon Willison dans un billet publié le 31 octobre 2026. Ce billet est notre seule source : nous ne rapportons que ce qu’il dit.

Une mini-application dans une « boîte » censée être fermée

Ce qui est en jeu : savoir si un contenu généré par l’IA, ou partagé par un tiers, peut toucher à votre compte.

ChatGPT peut produire de petites applications interactives, écrites en HTML, le langage de base des pages web. Simon Willison explique que ce modèle s’appelle « artifacts ». OpenAI le nommait « Canvas » et, selon lui, la dernière version s’appelle « HTML previews », soit aperçus HTML.

Ces applications s’affichent dans un « iframe » isolé, c’est-à-dire un cadre intégré à la page, tenu à l’écart du reste (on parle de « bac à sable »). Imaginez une vitre blindée : on regarde à travers, mais on ne touche à rien de ce qui est derrière.

Cet isolement compte. Selon Simon Willison, le HTML de ces aperçus doit rester étroitement confiné, pour qu’un code non fiable ne puisse ni dialoguer avec les services d’OpenAI ni accéder à des données privées.

En clair : la sécurité repose sur l’étanchéité de la vitre, et non sur la confiance dans le contenu affiché.

Comment l’isolement a été contourné

Ce qui est en jeu : comprendre qu’une faille grave peut naître de petits détails mis bout à bout.

Parameter Labs a trouvé, selon Simon Willison, une chaîne d’attaque assez complexe. Voici ses étapes, en simplifiant.

• Une bibliothèque tierce. Une bibliothèque est un morceau de code déjà écrit que l’on réutilise. OpenAI emploie MathLive, une bibliothèque en JavaScript (le langage qui fait fonctionner les pages web interactives), pour afficher des graphiques. MathLive inclut son propre clavier virtuel. La page principale peut le déclencher par un message envoyé depuis le cadre isolé, grâce à une fonction appelée postMessage(). C’est un peu un passe-plat entre deux pièces.
• Un message trop bien reçu. Le code qui réceptionne ce message utilise innerHTML, une instruction qui insère du HTML dans la page. Tout émetteur pouvait donc ajouter du HTML à la page parente. Selon le billet, rien n’empêchait les autres cadres isolés, dont ceux des aperçus HTML, d’appeler cette fonction.
• Un nouveau cadre sans restrictions. innerHTML n’exécute pas directement un script. Mais il pouvait servir à injecter un nouveau cadre, cette fois sans les limites de l’isolement.
• Une règle de sécurité détournée. OpenAI applique une CSP (Content Security Policy), une liste de règles qui dit au navigateur quels codes il a le droit d’exécuter. Celle-ci bloquait entièrement les scripts écrits dans la page et n’autorisait leur chargement que depuis quelques domaines. L’un d’eux était YouTube. Or le point d’accès « oEmbed » de YouTube, un service prévu pour intégrer une vidéo dans un autre site, pouvait renvoyer du JavaScript d’une manière qui le faisait s’exécuter.

En clair : les chercheurs ont enchaîné un message mal filtré, un cadre injecté et un domaine autorisé mais détournable. Chaque maillon semble mineur. Ensemble, ils ouvrent la porte.

Ce qu’un attaquant pouvait obtenir

Ce qui est en jeu : ce qu’un compte ChatGPT contient, et donc ce qui était exposé.

Une fois le JavaScript exécuté sur ChatGPT, il était, écrit Simon Willison, « trivial » de récupérer des données privées via les interfaces du service. Selon le billet, elles pouvaient ensuite sortir par une référence à une image.

Le billet ne détaille pas ce mécanisme. En général, ce type de fuite fonctionne ainsi : l’adresse de l’image est construite pour contenir les données volées, et le navigateur, en tentant de charger l’image, les transmet au serveur de l’attaquant. C’est notre explication du principe, pas un détail du billet.

Le scénario décrit est le suivant : on crée un lien de partage ChatGPT. Quand un autre utilisateur, connecté à son compte, ouvre ce lien, ses données privées peuvent être extraites. Des actions peuvent aussi être menées en son nom.

Le billet ne dit pas quelles données exactes étaient accessibles. Il ne dit pas non plus si cette faille a été exploitée par de vrais attaquants. Ces deux points restent ouverts.

En clair : dans ce scénario, un simple lien ouvert par une personne connectée suffisait, sans fichier à télécharger ni mot de passe volé au préalable.

Ce que l’on sait de la correction

Ce qui est en jeu : savoir si le problème est réglé, et à quel prix.

Selon Simon Willison, OpenAI a fermé la faille et versé une prime de 5 000 dollars. Il s’agit d’une « prime de bug », la récompense offerte aux chercheurs qui signalent un défaut plutôt que de l’exploiter. Pour lui, la somme est un peu maigre pour une vulnérabilité aussi sérieuse.

Ce que la source ne dit pas : la date de la correction, le délai entre le signalement et le correctif, ni la manière dont OpenAI a informé ses utilisateurs. Ces éléments ne sont pas documentés ici, et il vaut mieux ne pas les supposer.

Pourquoi un indépendant ou une PME est concerné

Ce qui est en jeu : ce que vous avez déjà déposé dans votre compte.

Beaucoup d’indépendants et de PME utilisent ChatGPT comme un carnet de travail. On y colle des courriels, des devis, des extraits de contrats, des listes de clients. L’historique des conversations et les fichiers restent dans le compte. Cette observation est la nôtre : le billet de Simon Willison ne décrit pas de cas d’entreprise.

Le raisonnement est simple. Plus un compte contient de choses, plus sa prise de contrôle coûte cher. Un outil jugé fiable est souvent un outil où l’on dépose trop.

Réflexes à garder

Ce qui est en jeu : réduire ce qu’une faille future pourrait exposer.

• Méfiez-vous des liens de partage. Un lien ChatGPT reçu d’un inconnu, ou d’un contact dont le message paraît étrange, mérite la même prudence qu’un fichier joint douteux. Dans le scénario décrit, c’est ce lien qui déclenchait l’attaque.
• Faites attention aux contenus générés par un tiers. Une mini-application ou un aperçu HTML produit ailleurs n’est pas forcément inoffensif.
• Triez ce que vous confiez. Évitez de déposer des données clients identifiables, des mots de passe ou des secrets d’entreprise. Ce qui n’est pas dans le compte ne peut pas en sortir.
• Nettoyez l’historique. Supprimez les conversations sensibles dont vous n’avez plus besoin.
• Sécurisez l’accès. Un mot de passe unique et l’authentification à deux facteurs restent utiles. Selon notre lecture, ils n’auraient a priori pas arrêté cette attaque, qui agissait depuis une session déjà ouverte. Le billet ne dit pas s’ils protègent contre ce scénario.

La question que cette affaire laisse ouverte : pour chaque donnée que vous confiez à un assistant IA, accepteriez-vous qu’elle soit lue par quelqu’un d’autre, le jour où une faille de ce genre réapparaîtra ?

Sources

• How We Took Over ChatGPT Accounts (Simon Willison)