Un lien ChatGPT partagé publiquement a pu exécuter du code attaquant dans votre session connectée. Voici ce qui a réellement cassé, pourquoi cela compte pour une entreprise qui tourne à l'IA, et ce qu'il faut corriger cette semaine.
Quelqu'un vous envoie un lien. Il ressemble à toutes les conversations ChatGPT partagées que vous avez déjà ouvertes : même domaine, même mise en page, un chat sur un graphique et un peu de HTML. Vous cliquez. Vous cliquez peut-être même sur le petit bouton Preview par curiosité.
C'était toute l'attaque. Selon la société de recherche Parameter, ce simple clic a permis à leur code de s'exécuter dans votre session ChatGPT authentifiée, avec les mêmes droits que le vrai site ChatGPT. De là, il a listé les conversations récentes, ouvert un chat privé qui n'avait jamais été partagé avec quiconque, et envoyé une partie de son contenu vers un serveur contrôlé par les chercheurs. Leur propre résumé est sans détour : ils pouvaient effectuer n'importe quelle action au nom du compte ChatGPT de la victime.
Parameter a signalé la faille via le programme de bug bounty d'OpenAI le 18 octobre 2026. OpenAI l'a corrigée le 26 octobre et l'a classée P1, sa catégorie la plus grave. Aucun usage réel n'a été constaté, et la preuve a été réalisée entre les propres comptes des chercheurs. Le correctif est déployé. Le schéma, lui, ne disparaît pas.
Cela a commencé par un graphique et un clavier
C'est la partie à lire deux fois, car elle explique pourquoi « nous avons corrigé le bug » n'est jamais la fin de l'histoire.
ChatGPT peut transformer un bloc de HTML dans une conversation en une petite page web fonctionnelle grâce à sa fonction Preview. Comme cette page peut contenir du code arbitraire, OpenAI l'exécute dans un cadre restreint, sur une autre adresse web. En soi, cette isolation tenait : le code de l'aperçu ne pouvait pas lire la page principale de ChatGPT.
La conversation contenait aussi un graphique interactif tout à fait ordinaire. En coulisses, ce graphique chargeait MathLive, une bibliothèque de composition mathématique. Le charger faisait plus que tracer une courbe : il installait dans la page principale de ChatGPT un listener pour les messages liés au clavier virtuel de MathLive.
Les navigateurs appellent cette API postMessage. Voyez-la comme une fente à courrier entre deux cadres par ailleurs scellés l'un à l'autre. Ce n'est sûr que si le destinataire vérifie qui envoie.
Le listener de MathLive utilisait une politique d'origine none, ce qui est une façon polie de dire qu'il acceptait les messages de n'importe quelle adresse web. La charge utile acceptée mettait à jour la disposition du clavier virtuel, et cette disposition pouvait contenir du HTML. À l'ouverture du clavier, la bibliothèque assemblait la disposition fournie dans une chaîne HTML et l'affectait à innerHTML dans la vraie page ChatGPT. Une fonction utilitaire nommée createHTML semblait assainir la valeur. Elle ne le faisait pas : elle marquait la chaîne comme fiable et la laissait passer telle quelle.
Deux fonctionnalités sans rapport. Un récepteur fiable, installé par un graphique. Un émetteur non fiable, fourni par un aperçu. Un pont au-dessus du bac à sable.
D'un message égaré à l'accès complet au compte
Les balises script insérées via innerHTML ne s'exécutent pas d'elles-mêmes, il fallait donc encore allumer la mèche. Les chercheurs ont utilisé un iframe avec l'attribut srcdoc, inséré sans attribut sandbox. Cela créait un document neuf où un script externe pouvait s'exécuter et, comme le cadre avait été créé par la page principale de ChatGPT, le navigateur lui accordait l'identité https://chatgpt.com. Le code dans ce cadre pouvait dès lors atteindre la page parente.
La Content Security Policy de ChatGPT bloquait le JavaScript en ligne, ce qui est exactement le rôle d'une bonne CSP. Elle autorisait en revanche les scripts provenant de YouTube. Le point d'accès oEmbed de YouTube acceptait un paramètre de callback de type JSONP et, fort utilement, plaçait ce callback dans sa réponse d'erreur avant de le valider. Comme YouTube figurait déjà dans la liste autorisée, le navigateur chargeait cette réponse comme un script et exécutait le callback de l'attaquant dans le nouveau cadre.
Résultat : du JavaScript arbitraire exécuté en tant que chatgpt.com, dans une session connectée, accessible par un lien.
Parameter a ensuite rendu la livraison ennuyeuse, au meilleur sens du terme pour un attaquant. Ils ont placé le graphique et l'aperçu dans une conversation publique ordinaire, l'ont exportée comme un lien /share/<id> classique et l'ont envoyée comme n'importe qui envoie un chat partagé : par e-mail, dans un message, dans un ticket de support, en publication sociale. Dans la version la plus stable, la victime cliquait une fois sur Preview. Dans une version ultérieure, l'aperçu s'ouvrait tout seul et l'alerte se déclenchait au bout d'environ 4,5 secondes. Ouvrir le lien était le seul clic.
Aucune installation. Aucune adhésion à un espace de travail. Aucun écran de consentement. Aucune page de phishing qui a presque l'air vraie.
Pourquoi votre entreprise doit s'en soucier malgré le correctif
Il est facile de classer cela en « bug OpenAI, déjà corrigé, passons ». Cette lecture manque les trois éléments qui mettent réellement votre organisation en danger.
Premièrement, la surface d'attaque était une fonctionnalité que l'on vous encourage à utiliser. Partager une conversation est une fonctionnalité de collaboration, et les fonctions de collaboration sont généralement fiables par défaut. Ici, c'était un lien qui transportait du code exécutable dans une session authentifiée.
Deuxièmement, la frontière de confiance était la session IA elle-même. Une fois le code exécuté, il n'avait pas besoin de lire les pixels de l'écran : il appelait les propres API authentifiées de ChatGPT en tant qu'utilisateur connecté. Tout contrôle qui observe ce sur quoi un humain clique sur la page ne voit rien.
Troisièmement, une évasion de bac à sable dans un produit est rarement un échec isolé. Cette chaîne est un tour d'horizon de raccourcis de développement très ordinaires : un listener de messages sans vérification de l'émetteur, un assainisseur qui marquait l'entrée comme fiable au lieu de la nettoyer, un iframe créé sans sandbox et une liste d'autorisations CSP assez large pour servir un attaquant. Ces schémas existent dans tous les projets qui ont câblé une intégration à la hâte. Y compris les nôtres.
La partie inconfortable : votre session IA, c'est tout votre contexte
Demandez-vous ce que contiennent les chats IA de votre équipe. L'architecture d'un client. Une clause contractuelle en cours de réécriture. Un plan de migration. Des identifiants collés une fois puis oubliés. Un modèle de prix encore en discussion.
Ce n'est pas un journal de conversation. C'est la concentration la plus dense de contexte métier que vous possédez, et elle est protégée par un seul cookie de session qui, en général, n'expire jamais.
La leçon n'est pas « l'IA est dangereuse ». La leçon est qu'une session IA mérite le même traitement qu'une console d'administration, pas le même traitement qu'un champ de recherche.
Ce que nous ferions cette semaine
- Traiter les sessions de chat IA comme des identités privilégiées. Exiger une réauthentification, raccourcir la durée de vie des sessions et imposer le SSO avec vérification de l'appareil là où le fournisseur le permet. Si le cookie de session peut lire tout le compte, il devrait expirer comme une session d'administrateur, pas comme un site favori.
- Supprimer les aperçus automatiques et les liens non vérifiés. Désactiver l'aperçu automatique des contenus partagés là où le réglage existe, et expliquer aux équipes qu'un lien inattendu est une charge utile, pas une politesse.
- Journaliser la couche API, pas l'écran. Si votre supervision ne voit que l'activité du navigateur, elle est aveugle à cette classe d'attaque. Suivez les appels authentifiés aux API du produit d'IA lui-même, avec des alertes de volume et de portée.
- Minimiser ce que la session peut atteindre. Séparez comptes personnels et professionnels. Gardez les documents confidentiels des clients hors des chats généraux. Utilisez les projets ou espaces de travail au périmètre plus strict quand ils existent, et supprimez ce dont vous n'avez plus besoin.
- Auditez vos propres intégrations pour les mêmes quatre erreurs. Listeners
postMessagenon vérifiés, puitsinnerHTML, iframes sans sandbox et listes d'autorisations CSP plus larges que nécessaire. C'est une revue de deux heures qui se rentabilise dès la première fois. - Examinez les fonctions de partage d'un fournisseur avant de les activer. Demandez ce qu'un artefact partagé peut faire dans la session de celui qui l'ouvre, pas seulement ce qu'il affiche.
À retenir
Le secteur vient de voir un lien partagé publiquement devenir un vecteur de livraison de code dans une session IA authentifiée, et le fournisseur l'a corrigé en huit jours, ce qui est réellement rapide.
Reste la question de conception que toute équipe qui construit sur l'IA doit désormais trancher : combien de contexte cette session contient-elle, combien de temps dure-t-elle, et qu'est-ce qui peut s'y exécuter ?
Chez aratech, nous construisons l'infrastructure IA sur laquelle nos clients opèrent, et c'est exactement la couture sur laquelle nous revenons sans cesse. Les agents, copilotes et assistants de chat ne sont pas des modules ajoutés à votre stack : ce sont des composants porteurs d'identité, avec accès à votre contexte le plus précieux. Traitez la session comme l'actif qu'elle est, et un lien arrivé dans un ticket de support devient une contrariété plutôt qu'un incident.
Si vous voulez un second regard sur ce que vos sessions IA peuvent atteindre, c'est exactement la conversation que nous aimons avoir.