Hack d’OpenAI avec Claude : ce que montre vraiment le récit de Hacktron

---

Un fil X peut donner l’impression que tout est simple : une image piégée, une IA, quelques heures, puis un accès à OpenAI. En réalité, le sujet mérite mieux qu’un résumé sensationnaliste.

Des chercheurs auraient “hacké OpenAI avec Claude”, la bonne question n’est pas seulement est-ce vrai ? C’est aussi : qu’est-ce qui est précisément documenté, à quel niveau d’accès, et avec quelles preuves ?

Ce que plusieurs sources concordantes permettent déjà d’établir

D’après l’article de The Verge, qui s’appuie notamment sur le tweet publié par Hacktron et sur l’article du Wall Street Journal, une équipe de trois chercheurs affirme avoir compromis des comptes d’employés OpenAI via une chaîne combinant Discourse, une faiblesse autour du traitement d’images HEIF et un problème lié au SSO OpenAI.

Le point important, c’est que cette version n’existe pas seulement sous forme de publication virale. Elle est aussi détaillée dans le thread Hacking OpenAI publié par Hacktron, avec une chronologie, une description de la chaîne d’exploitation et plusieurs visuels de démonstration.

Hacktron affirme notamment :

• avoir obtenu une exécution de code à distance sur l’instance Discourse liée à community.openai.com ;
• avoir ensuite exploité un défaut SSO côté OpenAI pour accéder à des comptes liés à ChatGPT et Codex ;
• avoir utilisé un compte d’employé affecté pour créer une pull request de preuve dans un dépôt interne, sans consulter le code sensible ;
• avoir signalé les vulnérabilités à OpenAI et à Discourse ;
• avoir reçu une prime de 6 500 dollars d’OpenAI pour la partie reconnue côté OpenAI, avec une précision importante sur le périmètre.

Ce dernier point compte beaucoup. Dans sa chronologie, Hacktron indique qu’OpenAI a précisé que les tests visant community.openai.com, hébergé par Discourse, étaient exclus du programme de bug bounty, et que la récompense reconnaissait la découverte côté OpenAI, pas les actions menées contre Discourse. Cette nuance va plutôt dans le sens d’un récit plus crédible que purement marketing.

Ce que montre vraiment le thread X de Hacktron

x.com

On July 25, we hacked OpenAI.

Two bugs let us take over ChatGPT/Codex accounts of OpenAI employees (+some unaffiliated users) and reach connected services: Outlook, Slack, GitHub, etc.

We proved it with a PR in OpenAI’s internal codebase . It took us <72h. 🧵 pic.twitter.com/gVsmQZwSc8

— s1r1us (@S1r1u5_) September 18, 2026

Le fil de s1r1us sur X ajoute une série de messages utiles pour comprendre ce que les chercheurs disent avoir atteint.

Ils y affirment notamment que :

• la chaîne allait d’un upload HEIC/HEIF à ImageMagick, puis à libheif, puis à une RCE sur community.openai.com ;
• le second problème, présenté comme le plus grave, était une vulnérabilité SSO OpenAI ;
• certains comptes affectés pouvaient être reliés à Outlook, Gmail, Google Drive, Slack, GitHub et d’autres services via Codex ou ChatGPT ;
• la preuve d’impact retenue a été une pull request inoffensive dans un dépôt interne OpenAI ;
• l’équipe a ensuite élargi ses recherches à d’autres cibles utilisant le même parseur d’images.

Le thread contient aussi des images qui illustrent ce récit, notamment un schéma de la chaîne d’exploitation, une capture de commit libheif, une capture de la preuve par pull request et une frise chronologique.

Ce que les images publiées montrent, sans extrapoler

C’est ici qu’il faut ralentir un peu 🔎. Une image publiée par des chercheurs n’est pas, à elle seule, une validation indépendante de tout le récit. Mais elle peut renforcer certains points précis.

La capture de la preuve par pull request, visible dans le billet Hacktron et dans le fil X, montre une reconstitution illustrative d’une action menée via Codex sur un dépôt présenté comme interne. Le texte de l’image précise d’ailleurs qu’OpenAI a demandé à ne pas inclure la capture originale, et que l’image publiée est une représentation reconstruite à des fins illustratives.

Autrement dit, cette image ne vaut pas preuve brute au sens forensique, mais elle documente la manière dont Hacktron dit avoir limité son exposition aux données sensibles.

Description proposée : La capture montre une interface sombre avec une tâche Codex et une modification légère d’un fichier README. Dans l’article, elle sert à illustrer la preuve d’impact revendiquée par Hacktron sans afficher la capture originale demandée par OpenAI.

Le schéma de la chaîne d’exploitation est également utile, parce qu’il résume visuellement le passage de libheif à ImageMagick, puis à Discourse, OpenAI SSO, ChatGPT/Codex, GitHub et enfin aux dépôts internes. Là encore, ce n’est pas une preuve indépendante, mais c’est un bon support pédagogique pour le lecteur.

Description proposée : Le visuel enchaîne plusieurs blocs, de libheif et ImageMagick jusqu’à Discourse, OpenAI SSO, ChatGPT/Codex, GitHub et les dépôts internes. Dans cet article, il aiderait à comprendre la logique technique générale sans la présenter comme preuve autonome.

Pourquoi l’histoire ne se résume pas à “Claude a hacké OpenAI”

C’est probablement la simplification la plus trompeuse.

Le billet Hacktron explique que Claude Opus 4.8 puis Opus 5 ont aidé à analyser l’environnement, identifier un problème autour de libheif, produire puis adapter un exploit, y compris avec des contraintes comme l’ASLR. Mais les chercheurs disent aussi explicitement que ce n’était pas du piratage complètement autonome et que la supervision humaine restait importante.

Cette nuance est essentielle 💡. Le récit documente davantage une accélération du travail offensif par des modèles avancés qu’un scénario où un agent aurait, seul, improvisé une compromission complète sans expertise humaine.

Autre nuance importante : plusieurs éléments chiffrés, relayés par The Verge et Hacktron, comme le “moins de 72 heures” ou le “moins de 3 000 dollars en tokens” pour le projet plus large, doivent être lus comme des déclarations propres à leur environnement de recherche. Ce ne sont pas des repères universels pour toutes les équipes offensives, tous les modèles ou toutes les cibles.

Ce que cet épisode dit vraiment aux équipes sécurité

Le point à distinguer est simple : il ne s’agit pas seulement d’une faille isolée, mais d’un enchaînement.

Selon le récit publié par Hacktron, la valeur de l’attaque vient du passage d’un composant bas niveau de traitement d’image à un service exposé, puis à une logique d’identité, puis à des connecteurs aval. En clair, le risque n’est pas “une image HEIF” en soi. Le risque, c’est l’assemblage suivant :

1. un parseur ou une dépendance vulnérable ;

2. une surface d’upload exploitable ;

3. un service connecté à un fournisseur d’identité ;

4. des intégrations aval trop permissives ou trop nombreuses.

C’est aussi pour cela que l’histoire intéresse au-delà d’OpenAI. Hacktron affirme avoir étendu sa recherche à Slack, Meta, GitHub Enterprise, Rails, Next.js, ImageMagick et d’autres composants ou environnements. Mais attention : cela reste, à ce stade, leur propre revendication, même si leur déclaration cite des références techniques comme l’advisory de sécurité Discourse, le release de maintenance sécurité de libheif v1.23.4 et l’annonce de Claude Opus 5 par Anthropic.

Ce qu’un décideur ou une équipe technique devrait vérifier avant de réagir

Inutile de copier en urgence la conclusion “tout service d’image est compromis”. La bonne réaction est plus méthodique :

• Quel niveau d’exposition avez-vous sur les uploads d’images ?
• HEIF, HEIC ou AVIF sont-ils réellement acceptés et nécessaires ?
• Le traitement passe-t-il par ImageMagick ou une chaîne équivalente ?
• Les correctifs de distribution et les backports sont-ils suivis, pas seulement les versions upstream ?
• Les services annexes connectés au SSO ont-ils des privilèges disproportionnés ?
• Une compromission d’un service périphérique peut-elle remonter vers des comptes centraux ?

Le billet Hacktron insiste d’ailleurs sur deux familles de réponses : mettre à jour les composants concernés et isoler davantage les pipelines de traitement d’images non fiables. C’est un enseignement raisonnable. Ce qui serait moins raisonnable, ce serait d’en faire une règle absolue sans cartographie de votre propre architecture.

Une lecture utile de cette affaire, sans dramatisation?

Ce dossier mérite l’attention, non parce qu’il “prouve que tout est exploitable”, mais parce qu’il montre à quel point des chaînes de dépendances, d’identité et d’intégrations peuvent amplifier un incident.

Ce que l’on peut retenir à ce stade, c’est ceci :

• un récit technique détaillé a bien été publié ;
• un fil X documenté existe et doit être embarqué comme source sociale primaire ;
• des visuels de démonstration ont été publiés, avec au moins une reconstitution explicitement signalée comme telle ;
• des correctifs ont été évoqués côté Discourse et côté OpenAI selon le récit disponible ;
• la part exacte de certains accès potentiels, notamment vers des services connectés comme Outlook, Gmail ou Slack, reste à lire comme impact revendiqué plutôt que comme impact intégralement vérifié publiquement.

>Cette affaire est utile si on la lit comme un rappel d’architecture, pas comme un spectacle. Une faille isolée fait déjà mal. Une faille reliée à un SSO et à des connecteurs métier peut faire beaucoup plus. Le vrai sujet n’est donc pas seulement “l’IA aide-t-elle les attaquants ?”, mais “combien de chemins latéraux votre système leur laisse-t-il encore ?”

Sources

Security researchers used Claude to help them hack into OpenAI, The Verge

Hacking OpenAI, Hacktron AI

Fil X original de s1r1us

libheif v1.23.4 security maintenance release