Neutron, notre moteur d’IA, a obtenu un score de 97,1 % sur le benchmark CyberGym de l’UC Berkeley. En savoir plus

Analyse approfondie

Analyse approfondie

ChatGPT : prise de contrôle de compte via un lien de partage et MathLive

Un lien de partage ChatGPT exécutait le JavaScript de l'attaquant dans la session de la victime via MathLive ; OpenAI a corrigé le 26 octobre.

En bref

  • Un lien de partage public ChatGPT malveillant pouvait exécuter le JavaScript de l'attaquant dans la session connectée de quiconque l'ouvrait, permettant d'agir comme ce compte ChatGPT. Parameter Security a signalé la chaîne à OpenAI le 18 octobre 2026.
  • Toute personne ayant ouvert une conversation partagée par un attaquant avant le 26 octobre 2026 était une victime potentielle : ni installation d'application, ni adhésion à un espace, ni connexion via l'attaquant n'étaient nécessaires, seulement l'ouverture du lien.
  • OpenAI a classé le rapport P1, et l'a corrigé côté serveur le 26 octobre 2026 dans les deux versions du frontend web. Aucune CVE n'est attribuée et aucun abus réel n'est signalé.
  • Le correctif ChatGPT est déployé. Les équipes intégrant MathLive doivent auditer leurs propres gestionnaires de messages ; la publication ne détermine pas leur état de correction.

Suis-je concerné ?

Comme utilisateur de ChatGPT, toutes ces conditions devaient être réunies :

  • Vous avez ouvert une conversation ChatGPT partagée via un lien public /share/ provenant d'une source non fiable, avant le 26 octobre 2026.
  • La conversation était conçue pour porter à la fois un graphique et un aperçu HTML (Preview).
  • Dans la version la plus fiable de l'attaque, vous avez cliqué une fois sur le bouton Preview de ChatGPT après l'ouverture de la page. Dans une version ultérieure, ouvrir le lien était la seule étape ; Parameter a reproduit ce chemin automatique trois fois, y compris après un rechargement complet.

La faille était dans le frontend web de ChatGPT et y est corrigée, donc ouvrir un partage piégé aujourd'hui n'exécute pas la charge. Parameter a mené sa preuve de lecture de conversation privée entre des comptes distincts qu'elle contrôlait, et ne signale aucun usage réel de la faille.

Si vous développez une application web qui intègre MathLive, la bibliothèque utilisée pour afficher les graphiques interactifs de ChatGPT, une exposition distincte s'applique :

  • Votre page charge MathLive, qui installe un écouteur postMessage pour son clavier mathématique à l'écran.
  • Un contenu influençable par un attaquant peut s'exécuter dans un cadre de la même page : aperçu intégré, widget isolé ou HTML rédigé par l'utilisateur.
  • L'écouteur traite un message qui modifie les réglages du clavier, car le contrôleur de niveau supérieur de MathLive acceptait le message depuis n'importe quelle origine.

Vérifiez si vos projets intègrent MathLive :

grep -A1 '"node_modules/mathlive"' package-lock.json
grep -rn "mathlive" --include=*.ts --include=*.js --include=*.vue --include=*.tsx src | head -20

Comment corriger ?

Les utilisateurs de ChatGPT n'ont rien à installer ni à réinitialiser. OpenAI a déployé le correctif dans les deux versions du frontend web, et au 26 octobre 2026 les deux rejettent les messages MathLive inter-cadres dont l'attaque dépendait.

Pour vos intégrations MathLive, la publication ne désigne aucune version amont corrigée. Le registre npm indique v0.111.1 comme dernière version, tandis que GitHub Releases affiche encore v0.100.0 : cette page ne constitue donc pas un inventaire complet des versions du paquet. Ne supposez pas qu’une mise à jour bloque cette chaîne sans vérifier les gestionnaires de messages. Appliquez les mesures de Parameter au niveau de l’intégration :

  1. Vérifiez l'émetteur avant de traiter tout message modifiant l'état : contrôlez à la fois event.origin, l'adresse web de l'émetteur, et event.source, la fenêtre exacte qui a reçu l'autorisation.
  2. Traitez les réglages inter-fenêtres comme des données, jamais comme du HTML : les dispositions de clavier et structures similaires ne doivent pas être assignées à innerHTML dans la page réceptrice.
  3. Gardez les documents créés dynamiquement isolés dès que leur contenu peut être influencé par un cadre non fiable, pour qu'un iframe srcdoc forgé ne puisse pas hériter de l'identité de votre page.
  4. Considérez la politique de sécurité du contenu comme un contrôle de secours, jamais comme la seule barrière une fois que du HTML contrôlé par l'attaquant atteint la page principale.

Ces mesures concernent la frontière de votre intégration. Consultez les avis de sécurité et les notes de version de la bibliothèque, puis vérifiez le traitement des messages concernés dans la version que vous déployez.

Quelle est la cause racine ?

Le bac à sable du Preview tenait ; une seconde fonctionnalité de la même page, le clavier à l'écran de MathLive, a laissé une porte ouverte au-delà. Le writeup de Parameter documente la chaîne de bout en bout.

ChatGPT affiche un bloc de code HTML via sa fonctionnalité Preview dans un cadre restreint sur une adresse web distincte, si bien que le cadre ne peut pas lire la page connectée qui l'entoure. Un graphique interactif de la même conversation charge MathLive, une bibliothèque de composition mathématique, dans la page principale chatgpt.com. Le chargement de MathLive installe un écouteur pour les messages de son clavier virtuel. Parameter a découvert que cet écouteur acceptait d'un émetteur quelconque un message modifiant la disposition du clavier, et que cette disposition pouvait porter du HTML brut. Le flux de contrôle déminifié était équivalent à :

window.addEventListener("message", (event) => {
  if (event.data?.type !== "mathlive#virtual-keyboard-message") return;
  if (!validateOrigin(event.origin, this.originValidator)) return;
  this.handleMessage(event.data, event.source);
});

if (message.action === "update-setting" && message.layouts) {
  this.layouts = message.layouts;
}

Parameter indique que le contrôleur de niveau supérieur utilisait une politique d'origine à none, ce qui signifie que n'importe quelle adresse web pouvait envoyer le message. Il n'exigeait pas non plus que le message update-setting vienne d'une fenêtre préalablement approuvée. La normalisation des dispositions conservait le champ markup, donc le HTML de l'attaquant survivait. Quand le clavier s'affiche, la disposition rejoint un puits HTML dans la vraie page ChatGPT :

keyboardContainer.innerHTML = MathfieldElement.createHTML(keyboardHtml);

L'assistant createHTML ressemblait à un assainisseur mais agissait comme un enveloppeur d'identité qui marquait la chaîne comme fiable et la laissait passer inchangée. Dans la synthèse de Parameter, trois décisions de conception ont transformé cela en exploit complet :

  • MathLive acceptait un message modifiant l'état sans prouver quel cadre l'avait envoyé.
  • Le format du message autorisait du HTML brut comme données de disposition de clavier.
  • Ce HTML pouvait créer un document non isolé héritant de l'identité chatgpt.com.

Comment est-ce exploité ?

  1. L'attaquant rédige une conversation ChatGPT contenant un graphique interactif authentique et, plus loin, un bloc HTML rédigé par l'assistant. Le graphique charge MathLive dans la page principale ; le bloc HTML est affiché en Preview.
  2. L'attaquant publie la conversation via la fonction de partage normale de ChatGPT et envoie à la victime le lien public /share/<id> par courriel, message, ticket ou réseau social.
  3. La victime ouvre le lien. Le cadre Preview envoie deux messages à la page principale : un message update-setting remplace une disposition de clavier virtuel par le HTML de l'attaquant, et un message show fait rendre à MathLive cette disposition.
  4. MathLive écrit le HTML dans innerHTML de la page principale chatgpt.com. Le HTML inséré est un iframe avec un attribut srcdoc et sans attribut sandbox, donc le navigateur crée un document neuf qui hérite de l'identité chatgpt.com.
  5. La politique de sécurité de contenu de ChatGPT bloque les scripts en ligne mais autorise ceux de www.youtube.com. Le cadre charge une URL oEmbed de YouTube dont le paramètre de rappel JSONP porte le JavaScript de l'attaquant, et le point de terminaison le renvoie dans sa propre réponse d'erreur de validation.
  6. Le rappel s'exécute dans le nouveau cadre comme chatgpt.com, avec la session connectée de la victime, et peut appeler directement les API authentifiées de ChatGPT.

Le code d'envoi des messages et l'URL YouTube sont publiés dans le writeup de Parameter, et les deux extraits ci-dessus en proviennent.

Comment se déroule l'attaque ?

Un lien de partage charge un graphique qui installe un écouteur fiable, et le Preview isolé s'en sert pour pousser du HTML d'attaquant dans la page principale, où un script YouTube autorisé achève le travail.

flowchart LR A["L'attaquant partage une conversation
avec un graphique et un Preview"] --> B["La victime ouvre le
lien public /share"] B --> C["Le graphique charge MathLive
dans chatgpt.com"] C --> D["Le Preview envoie update-setting
en postMessage (origine non vérifiée)"] D --> E["MathLive écrit le HTML de disposition
dans innerHTML (aucun assainissement)"] E --> F["iframe srcdoc non isolé
héritant de l'identité chatgpt.com"] F --> G["Le script JSONP YouTube s'exécute
(la CSP autorise youtube)"] G --> H["Le JS de l'attaquant agit comme la victime :
lit les conversations privées, toute action"]

Que peut faire un attaquant ?

La charge s'exécutait avec le même accès authentifié que la vraie page ChatGPT, donc sa portée n'était pas limitée à ce qui se trouvait à l'écran. Parameter a démontré trois capacités concrètes :

  • Elle énumérait les conversations récentes de la victime via GET /backend-api/conversations.
  • Elle récupérait le contenu d'une conversation privée jamais partagée avec l'attaquant, via le point de terminaison de détail de conversation.
  • Elle envoyait un fragment choisi de cette conversation vers un serveur contrôlé par les chercheurs, via une simple requête d'image.

La charge analysait les propres données d'amorçage de la page pour obtenir le jeton d'accès de session et l'identifiant de compte, et les utilisait dans les en-têtes de requêtes. L'évaluation de Parameter est que cela équivalait à un contrôle total du compte de la victime via l'application web. Les chercheurs écrivent : « essentially, we could perform any action on behalf of the victim's ChatGPT account ». La limite est ce que le frontend authentifié peut faire, pas les points de terminaison choisis par la preuve.

Les conditions étaient modestes : un compte ChatGPT ordinaire pour que l'attaquant rédige la conversation, un canal de distribution du lien, et au plus une interaction de la victime. OpenAI a classé le rapport P1 après avoir reproduit à la fois l'exécution de code et la preuve de lecture de conversation privée.

Pourquoi le correctif fonctionne-t-il ?

Le correctif d'OpenAI fait cesser la confiance de la page principale envers l'émetteur. Les deux versions du frontend web rejettent désormais les messages MathLive inter-cadres utilisés par le rapport. Un Preview non fiable ne peut donc plus remplacer une disposition de clavier ni injecter du HTML dans la page connectée. Le correctif est côté serveur ; les utilisateurs n'installent rien. Pendant le déploiement, OpenAI a aussi modifié la politique de sécurité de contenu, ce qui bloquait une partie de la chaîne pendant qu'une version du frontend attendait encore sa mise à jour.

L'étape YouTube était un contournement de la politique de sécurité de contenu, pas la cause, comme le note Parameter. Bloquer ce seul point de terminaison aurait supprimé un chemin vers JavaScript tout en laissant un Preview non fiable capable de pousser du HTML dans la page principale. Le correctif cible donc la frontière des messages, que chaque variante de charge devait franchir.

Comment vérifier si j'ai été compromis ?

Parameter ne fournit pas de méthode fiable pour détecter rétrospectivement cette exploitation. La charge utilisait la session existante du navigateur : un historique de sessions normal ne permet donc pas d’exclure une attaque. En cas de suspicion, examinez les sessions actives dans les réglages de sécurité de ChatGPT et suivez les conseils de sécurité d’OpenAI. Analysez les secrets potentiellement exposés et les journaux disponibles selon votre procédure de réponse aux incidents ; ne supposez pas qu’une lecture de conversation privée génère un événement d’export.

Pour vos propres intégrations MathLive, l'audit se fait côté code plutôt que côté journaux : cherchez chaque écouteur postMessage qui traite des réglages et confirmez que chacun vérifie l'émetteur. Un écouteur qui traite un message sans vérifier event.origin et event.source relève de la même classe de faille, quelle que soit la page.

Chronologie de la divulgation, du premier chemin confirmé le 13 octobre au correctif d'OpenAI le 26 octobre et au writeup public le 28 octobre.
Figure 1 : Parameter a confirmé le chemin d'injection le 13 octobre 2026, l'a signalé cinq jours plus tard, et OpenAI a corrigé les deux versions du frontend web le 26 octobre. Source : writeup de Parameter Security, vérifié le 31 octobre 2026.

Chronologie

  • 2026-10-13 : Parameter confirme le chemin message-vers-HTML de MathLive sur le code de production de ChatGPT.
  • 2026-10-14 : La chaîne est reproduite via l'interface normale et évoluée en JavaScript arbitraire.
  • 2026-10-16 : La livraison par partage public est confirmée entre comptes et espaces distincts, avec un clic sur Preview.
  • 2026-10-17 : Le Preview automatique depuis la navigation du partage est confirmé et reproduit après un rechargement complet.
  • 2026-10-18 : Parameter soumet le rapport au programme de primes à la vulnérabilité d'OpenAI.
  • 2026-10-19 : La preuve contrôlée de divulgation de conversation privée est ajoutée.
  • 2026-10-21 : OpenAI reproduit le problème et relève la sévérité de P2 à P1.
  • 2026-10-22 : OpenAI indique un frontend web corrigé pendant que le second est encore en mise à jour.
  • 2026-10-23 : Des changements de politique de sécurité de contenu bloquent une partie de la chaîne pendant qu'une mise à jour reste.
  • 2026-10-26 : OpenAI confirme que les deux frontends rejettent les messages signalés, clôt le problème et verse une prime totale de 5 000 dollars.
  • 2026-10-28 : Parameter publie le writeup technique.

FAQ

Les utilisateurs de ChatGPT ont-ils quelque chose à faire ?

Non. Le correctif est du côté d'OpenAI, déployé dans les deux versions du frontend web, et rien n'est à installer ni à réinitialiser.

La faille a-t-elle été exploitée dans la nature ?

Aucun usage réel n'est signalé. Parameter a mené la preuve de lecture de conversation privée entre ses propres comptes distincts, et The Hacker News rapportait le 31 octobre 2026 que la firme ne signale aucun usage réel. La sévérité venait de la capacité démontrée, pas d'abus observés.

MathLive lui-même est-il corrigé ?

La publication ne désigne aucune version corrigée de MathLive. Vérifiez le paquet installé et son traitement des messages ; GitHub Releases ne répertorie pas toutes les versions npm. Appliquez les contrôles d’intégration ci-dessus.

Pourquoi le bac à sable du Preview n'a-t-il rien bloqué ?

Le bac à sable a bloqué l'accès direct : le code dans le Preview ne pouvait pas lire la page principale de ChatGPT. L'entrée venait d'une seconde fonctionnalité de la même page. Le graphique chargeait MathLive, et l'écouteur de clavier de MathLive acceptait des instructions de n'importe quel cadre, ce qui permettait au Preview non fiable de remettre du HTML à la page de confiance.

Quelle était l'ampleur de l'exposition ?

Le frontend web de ChatGPT est l'une des applications les plus utilisées du web ; OpenAI elle-même rapportait 700 millions d'utilisateurs actifs hebdomadaires en septembre 2025. Tout utilisateur connecté susceptible d'ouvrir un lien partagé était concerné jusqu'au 26 octobre 2026. Portée ne veut pas dire impact ici : aucun abus réel n'est signalé.

La charge pouvait-elle faire plus que lire des conversations ?

Oui. La charge appelait les API authentifiées de ChatGPT avec la session de la victime, donc elle atteignait tout ce que le frontend normal atteint, pas seulement les conversations. Parameter a démontré la lecture d'une conversation privée et l'exfiltration d'un fragment choisi, et a évalué la primitive comme la capacité d'agir au nom du compte.

Repérez où vos propres applications intègrent MathLive avec Ostorlab

Si vos applications web intègrent MathLive, la première question est où. L'analyse de composition logicielle d'Ostorlab construit l'inventaire de dépendances de vos projets : un scan vous dit quelles applications tirent MathLive et où la revue d'intégration de « Comment corriger ? » doit avoir lieu.

Références

  • Parameter Security, Do the Math: How We Took Over ChatGPT Accounts, 28 octobre 2026 : https://www.parameter.ai/labs/we-found-a-gap-at-openai (vérifié le 31 octobre 2026)
  • The Hacker News, A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats, 31 octobre 2026 : https://thehackernews.com/2026/10/a-shared-chatgpt-link-could-run.html (vérifié le 31 octobre 2026)
  • Alertes de sécurité MathLive : https://github.com/arnog/mathlive/security/advisories (vérifié le 31 octobre 2026)
  • MathLive: https://registry.npmjs.org/mathlive/latest ; https://github.com/arnog/mathlive/releases
  • Page du paquet MathLive avec les chiffres de téléchargements hebdomadaires : https://www.npmjs.com/package/mathlive (vérifié le 31 octobre 2026)
  • OpenAI, How people are using ChatGPT (2025-09-15): https://openai.com/index/how-people-are-using-chatgpt/