Le 25 juillet 2026, trois chercheurs de la société de sécurité Hacktron ont pris le contrôle de comptes ChatGPT et Codex appartenant à des employés d'OpenAI. Pour le prouver sans consulter la moindre ligne de code confidentiel, ils ont demandé au Codex de l'un d'eux d'ouvrir une demande de fusion dans le dépôt interne openai/openai.
Entre la découverte initiale et cet accès, il s'est écoulé moins de 72 heures. Le compte rendu détaillé a été publié le 13 septembre, après correction des deux failles. OpenAI a versé une prime de 6 500 dollars.
L'intérêt de ce dossier ne tient pas au nom de la victime. Il tient au coût. La campagne de recherche dont cette intrusion fait partie a mobilisé trois personnes pendant deux mois et consommé moins de 3 000 dollars de tokens, pour un travail qui relevait jusqu'ici d'équipes spécialisées et de plusieurs mois d'effort par cible.
Une bibliothèque d'images, un défaut d'identité
La chaîne part d'un endroit banal. OpenAI héberge son forum communautaire sur Discourse, à l'adresse community.openai.com, et y autorise la connexion par « Sign in with OpenAI ». Les chercheurs ont fait l'hypothèse qu'une prise de contrôle du forum ouvrirait, par ce flux d'identité, un accès aux services d'OpenAI.
Restait à obtenir l'exécution de code sur le forum. Plutôt que d'attaquer Discourse, dont ils jugent le code difficile, ils ont visé une dépendance. Discourse vérifie normalement les images téléversées avec FastImage, mais cette bibliothèque ne gère pas le format HEIF. Les fichiers HEIC et HEIF étaient donc confiés à ImageMagick pour conversion, ce qui exposait directement l'analyseur libheif à des fichiers contrôlés par l'attaquant.
Le 23 juillet, une session Claude Opus 4.8 lancée sur l'image Docker de Discourse a identifié que certains correctifs de sécurité n'avaient pas été rétroportés dans le paquet libheif installé. La faille permet un dépassement de tampon dans le tas lors du décodage d'un fichier HEIC, avec lecture et écriture hors limites.
Le détail qui explique la persistance du trou : le correctif amont, publié l'année précédente, n'était pas documenté comme un correctif de sécurité et n'avait reçu aucun identifiant CVE. Debian 12, sur lequel repose l'image Docker de Discourse, installait donc la version vulnérable 1.19.7, et Debian 13 la 1.19.8. La mise à jour de sécurité Debian n'est arrivée que le 8 août 2026.
Le saut entre deux générations de modèles
La suite du récit est la partie qui intéresse le plus les équipes de sécurité. Le 24 juillet, Opus 4.8 produit un exploit fonctionnel avec la randomisation d'adresses désactivée. Plusieurs sessions séparées échouent ensuite à le rendre fiable contre la configuration par défaut de Discourse, randomisation activée.
Ce soir-là, Anthropic publie Claude Opus 5. Les chercheurs ouvrent une nouvelle session. En trois heures, le modèle produit un exploit fonctionnel en ARM64 sur un Mac local, puis le porte vers l'environnement x86-64 et la configuration jemalloc utilisée par Discourse. À 6 heures du matin le 25 juillet, l'exécution de code par téléversement d'image est confirmée en local.
Un point mérite d'être relevé tel quel. Pour obtenir un exploit visant une instance distante, les chercheurs ont placé le modèle dans une boucle autonome contre leur propre instance Discourse Cloud, en la faisant passer par un proxy pour qu'elle ressemble à une cible de capture de drapeau, « Opus refusant d'écrire un exploit pour des instances distantes ». Le garde-fou existait. Le requalifier en exercice a suffi.
À 10 heures, l'agent avait obtenu l'exécution de code sur l'instance de test et l'avait démontrée en lisant le fichier /etc/hosts. Le script généré a ensuite fonctionné sur l'instance d'OpenAI.
Ce que la faille SSO ajoute au tableau
Les chercheurs insistent sur un point que le nom de Discourse tend à masquer. La vulnérabilité qui transforme la compromission du forum en accès à ChatGPT et Codex n'est pas propre à Discourse : c'est un défaut de l'authentification unique d'OpenAI. N'importe quel service, interne ou tiers, s'appuyant sur ce mécanisme aurait produit le même résultat s'il avait été compromis.
La portée théorique dépasse le dépôt de code. Un compte ChatGPT ou Codex peut être relié à divers services, GitHub, Slack ou la messagerie, et ces connexions deviennent accessibles avec le compte. Les chercheurs ont pris le contrôle du compte d'un employé dont le Codex était relié à l'organisation GitHub d'OpenAI, envoyé une invite demandant l'ouverture d'une demande de fusion, puis cessé tout test.
La chronologie de correction est courte. Rapport soumis via Bugcrowd entre 8 et 10 heures UTC le 25 juillet, correctif OpenAI confirmé à 22 h 49 le même jour, soit environ quatorze heures. Discourse, saisi via HackerOne un samedi, a répondu le dimanche, disposait d'un correctif le lundi et a publié son avis GHSA-vhm9-85gw-x335 le 28 juillet, en ajoutant au passage un cloisonnement du traitement d'images.
Un élément de contexte sur la prime. OpenAI précise que les tests contre le forum hébergé par Discourse étaient explicitement exclus du périmètre de son programme, et que les 6 500 dollars récompensent la découverte côté OpenAI, pas les actions menées contre Discourse.
Une campagne, pas un incident isolé
L'intrusion chez OpenAI est un épisode d'un ensemble que Hacktron appelle HEIF Heist, une enquête de deux mois sur la présence de libheif dans les chaînes de traitement d'images de Slack, Meta, GitHub Enterprise, Ruby on Rails et des cadres Node.js comme Next.js, Astro et Gatsby. L'adaptation de l'exploit à chaque nouvelle cible prenait un ou deux jours.
Les chercheurs décrivent une méthode qui part presque à l'aveugle : téléversement d'une image, puis transformation de la corruption mémoire en fuite de mémoire ou en accès interactif, sans connaître la version exacte de libheif, celle de la bibliothèque C ni l'environnement de déploiement. Ils notent un second saut de capacité entre Opus 5 et GPT-5.6 Sol sur précisément cette tâche, l'exploitation sans connaissance du système cible.
Ils ajoutent une observation que les responsables de la sécurité devraient prendre au sérieux : à leur connaissance, une seule entreprise, Shopify, a détecté l'activité, alors que des milliers d'images avaient été envoyées et que les processeurs d'images plantaient de façon répétée.
La démarche n'est pas présentée comme du piratage autonome. Quand l'exécution de code atterrissait dans un bac à sable, les modèles ont aidé à l'élévation de privilèges, au déplacement latéral et au contournement des défenses, mais la conduite humaine restait déterminante. Ce qui change, écrivent-ils, est la quantité de travail qu'une petite équipe peut abattre.
Ce qui tombe avec cette démonstration
L'argument final du rapport vise une protection dont peu d'organisations mesurent qu'elles en dépendent. Une vulnérabilité mémoire pouvait être publique, et son exploitation fiable rester hors de portée : elle demandait une expertise rare, du temps et une connaissance fine de l'environnement cible. Cette difficulté n'a jamais été une frontière de sécurité, mais elle protégeait en pratique les entreprises ordinaires.
Convertir cette expertise en calcul la fait disparaître. Pour une direction technique, la conséquence est concrète et se décline en trois questions. Quelles dépendances de traitement de fichiers, images comprises, tournent en production sans être suivies au niveau du paquet distribution ? Un correctif amont non étiqueté « sécurité » déclenche-t-il quelque chose dans la chaîne de mise à jour ? Et une authentification unique interne donne-t-elle, via un assistant connecté, un accès qu'aucune revue n'a modélisé ?
Hacktron recommande de désactiver le décodage HEIF et AVIF non nécessaire, ou d'isoler les chaînes de traitement d'images dans des bacs à sable éphémères. La dernière version de sécurité amont de libheif était la 1.23.4 au 14 septembre 2026, la 1.23.2 ayant elle-même été dépassée par des correctifs ultérieurs. Les paquets de distribution pouvant porter des correctifs rétroportés sous un numéro plus ancien, le numéro de version seul ne suffit pas à conclure.