Les liens de partage ChatGPT permettaient l'exécution de code dans les sessions utilisateur
Des chercheurs ont découvert une vulnérabilité dans les liens de partage de ChatGPT permettant aux attaquants d'exécuter du code et de lire des chats privés. OpenAI a corrigé le défaut en huit jours.
Traduit automatiquement depuis l'original anglais.
Les chercheurs en sécurité de Parameter ont découvert une vulnérabilité critique dans ChatGPT qui permettait l'exécution de code malveillant au sein de la session connectée d'une victime via un lien de conversation partagée. Le défaut, signalé le 18 octobre 2026, permettait aux attaquants d'accéder à des chats privés et d'agir au nom de l'utilisateur. OpenAI a classifié le problème avec une sévérité P1 et a déployé un correctif avant le 26 octobre.
Ce qui s'est passé
Le vecteur d'attaque reposait sur la fonctionnalité standard de ChatGPT permettant aux utilisateurs de partager des conversations via des liens publics. Un attaquant pouvait concevoir une conversation spécifique contenant des éléments malveillants et la partager par e-mail, réseaux sociaux ou tickets de support. Lorsqu'une victime ouvrait ce lien, elle n'avait pas besoin d'installer un logiciel ni de se reconnecter ; l'exploit visait sa session authentifiée existante. Dans la preuve de concept initiale, la victime devait cliquer une fois sur le bouton Preview (Aperçu). Une version affinée automatisait cette étape, nécessitant uniquement que la victime ouvre le lien.
Une fois déclenché, le code de l'attaquant s'exécutait avec les mêmes privilèges que l'interface légitime de ChatGPT. Cela permettait au script malveillant d'appeler directement les API signées, de lister les conversations récentes et d'ouvrir des chats privés qui n'avaient jamais été partagés. Les chercheurs ont démontré qu'ils pouvaient exfiltrer des portions de ces discussions privées vers un serveur externe. Parce que le code opérait dans le contexte complet d'accès web de la victime, ses capacités allaient au-delà de la simple lecture de l'historique des chats pour effectuer toute action que le titulaire du compte pouvait réaliser.
Parameter a réalisé ce travail comme un test contrôlé entre des comptes distincts et n'a trouvé aucune preuve d'exploitation réelle. Ils ont soumis leurs conclusions via le programme de bug bounty d'OpenAI. OpenAI a initialement évalué la sévérité comme P2 mais l'a rehaussée à P1 après avoir reproduit l'exploit. La société a versé un total de 5 000 $ pour le rapport et a déployé des correctifs sur deux versions de son frontend web.
Comment cela fonctionne
La vulnérabilité est née d'une interaction entre trois fonctionnalités distinctes : le sandbox Preview, la bibliothèque MathLive et la messagerie inter-frame. ChatGPT utilise un frame sandboxé sur un domaine séparé pour rendre les aperçus HTML, empêchant ceux-ci d'accéder à l'état principal de l'application. Cette isolation tenait bon seule. Cependant, le chat partagé incluait également un graphique interactif qui chargeait MathLive, une bibliothèque mathématique, dans la page principale.
MathLive inclut un écouteur pour les messages concernant son clavier virtuel. Parameter a découvert que cet écouteur acceptait les messages de tout expéditeur sans vérifier l'origine de la source. Crucialement, ces messages étaient autorisés à transporter des données HTML brutes destinées à la personnalisation de la mise en page du clavier. Le frame Preview malveillant exploitait cela en envoyant un message conçu contenant du HTML contrôlé par l'attaquant à l'écouteur MathLive sur la page principale.
Ce HTML créait un nouveau frame que le navigateur traitait comme faisant partie du domaine trusted chatgpt.com, contournant le sandbox. Pour exécuter la charge utile finale, les attaquants ont exploité les scripts YouTube, qui étaient sur liste blanche dans la politique de sécurité du contenu de ChatGPT. Bien que le code inline soit bloqué, les scripts provenant de domaines autorisés comme YouTube pouvaient s'exécuter dans ce nouveau frame trusted, donnant à l'attaquant un contrôle total sur la session.
Détails clés
- La vulnérabilité a été signalée le 18 octobre 2026 et corrigée le 26 octobre 2026.
- OpenAI a classifié le problème P1, sa catégorie de sévérité la plus élevée, après l'avoir initialement classé comme P2.
- L'attaque ne nécessitait aucune installation utilisateur ni étapes de connexion supplémentaires au-delà de l'ouverture d'un lien partagé.
- L'exploitation reposait sur l'acceptation par MathLive de messages inter-frame non vérifiés contenant du HTML brut.
- Les attaquants ont utilisé des scripts YouTube sur liste blanche pour contourner les politiques de sécurité du contenu et exécuter du code.
- Parameter a reçu une prime de 5 000 $ pour la divulgation responsable du défaut.
Pourquoi c'est important
Cet incident met en lumière les risques inhérents aux applications web complexes qui intègrent des bibliothèques tierces et un rendu dynamique de contenu. Pour les ingénieurs développant des interfaces IA, cela souligne l'importance d'une validation stricte pour la communication inter-frame. Même lorsque les sandboxes sont correctement implémentés, des vulnérabilités peuvent surgir de la manière dont différents composants interagissent. La dépendance à des bibliothèques externes comme MathLive introduit des risques liés à la chaîne d'approvisionnement qui doivent être gérés par une validation rigoureuse des entrées et une vérification des origines.
Pour les équipes produit, la rapidité de la réponse d'OpenAI démontre la valeur des programmes robustes de bug bounty et des protocoles clairs de réponse aux incidents. La capacité à détecter, reproduire et patcher une vulnérabilité P1 en huit jours minimise les dommages potentiels. Cependant, le fait que le défaut ait permis une compromission complète du compte sert de rappel que les fonctionnalités partagées doivent être conçues selon les principes du moindre privilège, garantissant que les modes d'aperçu ne peuvent pas escalader les privilèges vers le contexte principal de l'application.
Ce que vous pouvez faire
- Vérifiez que tous les écouteurs de messages inter-frame valident l'origine des messages entrants.
- Évitez d'autoriser l'injection de HTML brut via les charges utiles des messages, même pour les données de configuration.
- Examinez les politiques de sécurité du contenu pour garantir que seuls les domaines nécessaires sont sur liste blanche pour les scripts.
- Implémentez un sandboxing strict pour toutes les prévisualisations de contenu généré par l'utilisateur et les éléments interactifs.
- Menez des audits de sécurité réguliers portant sur les interactions entre les bibliothèques tierces et la logique centrale de l'application.
- Encouragez la divulgation responsable en maintenant un programme de bug bounty accessible pour vos produits.



