HEIF Heist de Hacktron : une bibliothèque d'images non corrigée a ouvert la porte au monorepo d'OpenAI

Le 18 septembre 2026, l'équipe de sécurité Hacktron AI a publié une chaîne d'exploitation en plusieurs étapes qui a commencé par le téléversement d'une image ordinaire et s'est achevée dans le code source privé d'OpenAI. L'analyse technique, intitulée Hacking OpenAI, décrit comment trois chercheurs ont atteint le monorepo interne de l'entreprise en moins de 72 heures, et comment un correctif jamais étiqueté comme tel a laissé la porte ouverte.

À lire aussi: Une faille sans clic laisse des plugins malveillants exécuter du code dans quatre grands agents de codage IA · Selon des chercheurs, l'essaim d'agents d'OpenAI a inondé RubyGems de 2 000 gemmes malveillantes.

Le travail a été mené le 25 juillet 2026 et divulgué seulement après que les projets concernés ont livré leurs correctifs. Hacktron affirme que son chemin n'a jamais dépendu d'un mot de passe mal saisi, d'un courriel d'hameçonnage ou d'un employé complaisant. Il a combiné une faille de sûreté mémoire dans un décodeur d'images avec un défaut de configuration d'identité, et s'est servi de l'une pour amplifier l'autre. L'équipe, composée de Harsh Jaiswal, Mohan Pedhapati et Rahul Maini, a ensuite étendu ses recherches sur le décodeur à une campagne qu'elle nomme HEIF Heist.

Comment la chaîne a fonctionné

Le chemin documenté comporte quatre étapes, et chacune est banale prise isolément.

Première étape : une image atteint une bibliothèque en C. community.openai.com est un forum d'OpenAI qui tourne sous Discourse. Discourse inspecte les téléversements avec FastImage, qui ne prend pas en charge le HEIC ni le HEIF, les formats qu'un iPhone produit par défaut. Les fichiers de ces formats passent alors à la commande magick d'ImageMagick, qui les remet à libheif, un décodeur en C/C++. Selon le récit des chercheurs, téléverser un fichier HEIC trafiqué suffisait donc à envoyer des octets contrôlés par l'attaquant directement dans un analyseur natif.

Deuxième étape : l'analyseur casse. libheif contenait un débordement de tampon sur le tas, référencé sous CVE-2026-32882 avec un score CVSS de 8,8. Le déclencher pendant le décodage HEIC donnait des primitives de lecture et d'écriture hors limites, que l'équipe a transformées en exécution de code à distance sur le conteneur du forum. Le détail qui compte le plus se trouve dans l'histoire de ce code : la source amont l'avait modifié près d'un an plus tôt dans un commit de nettoyage de routine, sans avis de sécurité ni CVE. Debian n'a donc jamais rétroporté la modification. Debian 12 et Debian 13 livraient toutes deux une version vulnérable de libheif, et l'image Docker de Discourse, fondée sur Debian 12, en a hérité. Debian a publié DSA-6417-1 pour Debian 13 le 8 août 2026.

Troisième étape : le forum donne accès aux comptes OpenAI. Avec une exécution de code à distance administrative sur le forum, l'équipe a abusé d'une configuration défectueuse de l'authentification unique d'OpenAI sur auth.openai.com. Le forum proposait « Sign in with OpenAI », si bien qu'une session sur community.openai.com avait du poids sur les produits grand public d'OpenAI. Hacktron pouvait détourner les sessions ChatGPT et Codex d'employés d'OpenAI connectés, sans aucune action de la victime. Les chercheurs soulignent que cette étape relevait d'un problème d'identité d'OpenAI et non d'un défaut de Discourse, et que tout service interne ou tiers utilisant le même SSO aurait ouvert la même porte.

Quatrième étape : une preuve, pas un vol. À l'aide du Codex d'un employé, connecté à l'organisation GitHub d'OpenAI, l'équipe lui a demandé d'ouvrir une demande de fusion inoffensive, la PR #1186742, dans le monorepo interne openai/openai, puis s'est arrêtée. Hacktron affirme n'avoir ni lu ni exfiltré de code interne. Une demande de fusion ouverte depuis l'intérieur du périmètre de l'entreprise démontre l'accès en écriture plus proprement qu'une capture d'écran, et c'est le genre de preuve sur lequel un programme de primes peut agir.

Un forum est une cible de faible valeur jusqu'à ce qu'il soit relié au système d'identité qui protège tout le reste. C'est ce câblage que Hacktron a chevauché jusque dans les comptes d'OpenAI.

Pourquoi le correctif sans étiquette est la vraie histoire

Le titre, c'est que des chercheurs ont atteint le code interne d'une entreprise d'IA. La leçon la plus transposable concerne ce qui se passe quand un travail de sécurité est livré sans étiquette de sécurité.

Les bases de données de vulnérabilités s'appuient sur des identifiants. Les distributions décident de ce qu'elles rétroportent à partir des avis, des CVE et des notes de version. Quand un correctif de sûreté mémoire arrive comme une maintenance de routine sous un titre neutre, aucun de ces signaux ne se déclenche. La modification de libheif a été considérée comme du nettoyage, l'écosystème n'avait donc aucune raison de regarder, et la version vulnérable a gardé sa place dans les images de conteneur longtemps après que le code avait été corrigé à la source. Le récit de The State of AI présente l'exposition de façon comparable : le bug était corrigé, mais personne ne savait qu'il fallait le dire.

Cet écart n'est pas rare, et il prend de l'importance à mesure que les piles logicielles s'épaississent. Ce bug ne vivait pas dans un forum, un framework ou une application. Il se trouvait plusieurs couches plus bas, dans un décodeur qui parvient en production par des enveloppes comme ImageMagick, libvips et sharp, et par des images de base préconstruites que peu d'équipes mettent à jour à la main. Une entreprise peut suivre ses dépendances directes avec soin et rester exposée par une dépendance transitive qu'elle n'a jamais listée.

Les numéros de version ne sont pas non plus une vérification fiable à eux seuls. Une distribution peut rétroporter un correctif sans changer la version amont apparente, et un conteneur peut épingler un ancien paquet système même après la reconstruction de l'application au-dessus. L'analyse de lilting.ch le dit clairement : ce qui compte, c'est la version réellement exécutée, ce qui impose de lire l'avis de sécurité de la distribution avec le journal des modifications du paquet plutôt que de se fier à une chaîne dans un fichier de verrouillage.

Discourse a agi vite dès qu'il a eu le rapport. Il a ajouté un bac à sable autour d'ImageMagick, livré un correctif le lundi 27 juillet et publié l'avis GHSA-vhm9-85gw-x335 le 28 juillet 2026. Le bac à sable est la partie à copier. Les failles de sûreté mémoire dans les analyseurs d'images continueront d'apparaître, aussi la défense durable consiste à supposer qu'un décodeur sera compromis et à le placer là où une compromission n'atteint pas l'hôte, plutôt qu'à parier sur l'arrivée à temps du prochain correctif.

La couche d'identité a transformé un bug de forum en problème d'entreprise

Un forum communautaire est une cible de faible valeur dans la plupart des modèles de menace. Il contient des discussions, pas des secrets. Cette hypothèse se brise au moment où le forum utilise le fournisseur d'identité de l'entreprise pour la connexion.

Parce que community.openai.com autorisait « Sign in with OpenAI », une compromission du serveur du forum est devenue un point d'appui dans le flux d'identité. Hacktron a pu détourner les sessions ChatGPT et Codex d'employés et d'autres membres actifs du forum sans tromper personne. La portée potentielle dépassait ChatGPT : les comptes sont souvent reliés à d'autres services, et les chercheurs citent GitHub, Slack et le courriel parmi les intégrations qu'une session détournée pourrait toucher.

La leçon dépasse largement OpenAI. Toute organisation qui laisse des propriétés tierces ou communautaires s'authentifier via son système d'identité d'entreprise a créé un chemin du service le moins fiable vers les comptes les plus fiables. La délimitation de portée compte ici autant que la correction. Un jeton de connexion émis pour un forum de discussion ne devrait pas porter l'autorité d'un identifiant d'API pour les produits phares de l'entreprise, et le correctif déployé par OpenAI portait sur cette configuration d'identité, pas sur Discourse.

Le rapport de Cyber Kendra sur la divulgation cadre la même séparation : le forum était le point d'entrée, mais l'escalade qui comptait était la confiance accordée à une session. Examiner quelles applications peuvent émettre des jetons pour quels publics, et raccourcir la durée de vie de ces jetons, fait plus contre cette classe d'attaque que n'importe quel correctif de serveur isolé.

Les exploits écrits par l'IA ont changé le rythme

Le développement d'exploits était autrefois un goulot d'étranglement qui favorisait les défenseurs. Transformer une primitive de lecture ou d'écriture hors limites en charge utile fiable suppose de vaincre la randomisation de l'espace d'adressage et de viser l'allocateur de la cible, un travail qui prenait des jours ou des semaines à un spécialiste.

Le récit de Hacktron montre ce goulot qui s'amincit. L'équipe affirme que Claude Opus 4.8 a analysé l'image Discourse et découvert que des correctifs de sécurité n'avaient pas été rétroportés dans son paquet libheif, mais qu'il n'a pas réussi à produire un exploit fonctionnel avec l'ASLR activé, sur plusieurs sessions. Quelques heures après la sortie de Claude Opus 5 par Anthropic, la même consigne a produit un exploit ARM64 fonctionnel en environ trois heures. L'équipe a ensuite demandé au modèle de le porter vers la configuration x86-64 et jemalloc qu'utilise Discourse, et au petit matin du 25 juillet, l'exécution de code par téléversement d'image était confirmée.

Les chercheurs ont fait tourner le modèle dans une boucle autonome contre une instance qu'ils contrôlaient et qui ressemblait à une cible de capture du drapeau, car le modèle avait refusé d'écrire un exploit visant un système distant en production. Le même script généré a ensuite fonctionné contre le forum d'OpenAI. Ce qu'il faut retenir n'est pas quel modèle a gagné, mais que la limite est passée de « aucun exploit fonctionnel » à « exploit fonctionnel en trois heures » en un seul cycle de version, et que les parties difficiles et répétitives de l'exploitation sont précisément celles qu'un agent peut mener sans relâche.

Ce qu'il faut surveiller

Trois choses décideront du poids de cette histoire. La première est de savoir si le reste des découvertes de HEIF Heist se transforme en avis. Hacktron affirme que la même classe de décodeur a atteint Slack, les produits phares de Meta, Next.js et GitHub Enterprise Server, où une faille apparentée est référencée sous CVE-2026-19118 et a été corrigée dans la version 3.21.5 le 1er septembre 2026. Vercel a désactivé l'optimisation AVIF sur son service géré pendant que le correctif amont se propageait. Si d'autres éditeurs confirment des chemins similaires, la leçon passe d'un forum à toute la chaîne d'approvisionnement du traitement d'images.

La deuxième est la vitesse à laquelle les consommateurs en aval bougent réellement. Les utilisateurs de libheif en amont sont invités à atteindre la version 1.23.2 ou ultérieure, et la dernière version de sécurité était la 1.23.4 à la mi-septembre 2026. Là où le décodage HEIF ou AVIF n'est pas nécessaire, il convient de le désactiver au niveau applicatif. Là où il l'est, le traitement d'images doit se faire dans un bac à sable durci et éphémère, comme le fait désormais Discourse.

La troisième est la portée de l'identité. La découverte concernant OpenAI a été corrigée environ 14 heures après le rapport, et l'entreprise a versé une prime de 6 500 dollars tout en précisant que les tests visant le forum lui-même sortaient du périmètre de son programme de primes. Cette séparation reflète équitablement l'origine de la faute, mais elle signifie aussi que la leçon la plus réutilisable, à savoir qu'un forum communautaire ne devrait pas être un passe-partout, est encore en train d'être assimilée dans le secteur.

Image de couverture : Wikimedia Commons « Person holding the OpenAI icon.jpg » de FoxTPNL, CC BY 4.0 (recadrée en 16:9).