Quand une technique s’installe dans un métier, elle absorbe d’abord le geste le plus coûteux en savoir-faire et laisse le jugement au praticien : la photographie n’a pas supprimé le portraitiste, elle a comprimé les heures de pose. La sécurité informatique offensive avait, elle aussi, son maillon cher. Le plus dur n’a jamais été de repérer qu’un logiciel contient une faiblesse, mais de la transformer en une attaque qui fonctionne pour de bon, sur une machine réelle, malgré les protections du système : un travail de plusieurs semaines que peu savent mener.
Trois chercheurs de Hacktron AI, Harsh Jaiswal, Mohan Pedhapati et Rahul Maini, viennent de montrer que ce maillon peut céder en quelques heures. Révélée cette semaine par les intéressés puis relayée par le Financial Times, leur opération a mené, en moins de soixante-douze heures, d’une première inspection aux dépôts de code internes d’OpenAI, avec l’aide d’un modèle concurrent, Claude. L’affaire remonte au 25 juillet. Il faut en suivre la chaîne : la porte d’entrée, le rôle du modèle, ce qu’il a comprimé et ce qu’il n’a pas touché.
Une chaîne de deux maillons, bouclée en moins de 72 heures
L’entreprise cherchait depuis des mois des faiblesses chez les sociétés d’IA quand elle a repéré deux défauts qui, isolés, ne menaient nulle part, mais qui, enchaînés, ouvraient un chemin vers les systèmes d’OpenAI. Le premier permettait d’exécuter du code sur la machine hébergeant le forum communautaire de l’entreprise ; le second tenait à une mauvaise configuration de son authentification unique. L’un donnait pied sur une machine périphérique, l’autre changeait ce pied en accès aux comptes des salariés.
En les combinant, les chercheurs se sont emparés de plusieurs comptes ChatGPT et Codex de salariés d’OpenAI. L’un de ces comptes Codex, l’agent de programmation de la maison, ouvrait sur l’organisation GitHub interne. Pour établir cet accès sans lire les dépôts, ils y ont fait ouvrir une proposition de modification, puis ont arrêté leurs tests et signalé leurs découvertes. Le billet détaillant l’opération n’a paru que le 13 septembre, après correction : une divulgation coordonnée, pas un coup d’éclat.
Le calendrier à l’heure près
La chronologie tient sur trois jours. Le 23 juillet, l’équipe commence à examiner la chaîne de traitement des images du forum ; le 24, elle met au point une première version de l’attaque ; le 25 au petit matin, entre 5 et 6 heures UTC, elle obtient l’exécution de code et un accès administrateur ; le rapport part dans la matinée, le compte d’un salarié est compromis et la proposition déposée en début d’après-midi. OpenAI confirme un correctif à 22 h 49, quatorze heures après le signalement. Discourse, prévenu le jour même, corrige le 27 et publie le 28 juillet un avis classant la faille grave, avant de renforcer l’isolation de son traitement d’images.
La preuve sans lecture du code
Le geste de preuve dit la prudence de la démarche. Plutôt que de parcourir des dépôts confidentiels, les chercheurs ont fait ouvrir par le Codex du salarié une proposition de modification portant sur un simple fichier de description. OpenAI indique que son examen n’a relevé que des lectures limitées de métadonnées et de commits de dépôts privés, suivies de cette proposition, avant l’arrêt des tests.
La différence avec les épisodes récents où un modèle s’échappait de son environnement d’essai est ici entière : personne n’a laissé une machine décider seule. À chaque bifurcation, des humains ont choisi la cible, guidé l’outil et fixé la limite. Le fait neuf n’est pas une IA qui s’émancipe, mais une petite équipe qui, grâce à elle, abat en trois jours un travail qui en demandait bien davantage.
Le décodeur d’images, la porte d’entrée
La brèche passe par libheif, une bibliothèque libre qui décode les formats HEIC, HEIF et AVIF des photos d’iPhone. Le forum ne l’appelle pas directement : son outil habituel de vérification ne sait pas lire le HEIF et confie ces fichiers à la commande de conversion d’ImageMagick, qui s’appuie sur libheif. Le décodeur, écrit dans un langage sans garde-fou mémoire, se retrouve exposé à un fichier venu de l’extérieur : une image spécialement préparée suffisait à provoquer un débordement de mémoire et, de fil en aiguille, l’exécution de code sur le serveur.
Le correctif silencieux
C’est là que le modèle est d’abord intervenu, non pour attaquer mais pour lire. Les chercheurs ont d’abord fait examiner par Claude Opus 4.8 la version de libheif que faisait tourner le forum. Le modèle a constaté que certains correctifs apportés en amont au projet libre n’avaient jamais été répercutés sur la version installée : le défaut avait été réparé chez les développeurs d’origine, mais pas là où il comptait.
Cette réparation manquante est un cas d’école. Le commit qui corrigeait la faiblesse portait un intitulé de maintenance ordinaire, sans avis de sécurité ni CVE : rien n’a donc déclenché son rétroportage dans les distributions, et l’image du forum, sous Debian 12, faisait encore tourner une version exposée de libheif, la 1.19.7, cataloguée plus tard CVE-2026-32882. Le modèle a fait en quelques minutes ce que l’écosystème n’avait pas fait en un an : repérer une correction passée sous silence, de sorte que ces n-days invisibles deviennent une matière première pour l’IA offensive.
Une surface d’attaque déjà ancienne
Rien de tout cela n’est neuf dans son principe. Les décodeurs d’images sont une porte d’entrée éprouvée : ImageTragick permettait déjà, en 2016, l’exécution de code via des images confiées à ImageMagick, et les exploits zéro-clic FORCEDENTRY puis BLASTPASS, au début des années 2020, passaient par un décodeur d’image sans le moindre geste de la victime, tiré d’une dépendance indirecte invisible à qui déploie le service. L’attaque contre OpenAI n’est qu’un cas d’un programme plus vaste, baptisé HEIF Heist, qui a aussi visé Slack, Meta, GitHub Enterprise ou Next.js. Discourse a fini par confiner son traitement d’images dans un bac à sable du noyau Linux, recommandé il y a dix ans.
De l’analyse à l’arme
Repérer le défaut ne suffisait pas : restait à le rendre exploitable en conditions réelles, le maillon cher. Opus 4.8 a produit une première version de l’attaque, mais elle cessait de fonctionner dès que les protections mémoire ordinaires du système étaient activées. La démonstration tenait en laboratoire et se dérobait devant une configuration défendue.
L’écart d’un jour entre deux modèles
Le déblocage est venu d’un changement de modèle, à vingt-quatre heures d’intervalle. Claude Opus 5, sorti le soir du 24 juillet, a produit en moins de trois heures une attaque fonctionnelle sur un Mac à processeur ARM64, puis l’a portée sur x86-64 et sur l’agencement mémoire propre à Discourse. Au matin suivant, une simple image envoyée au forum suffisait à y faire exécuter du code à distance. La frontière de l’exploitable avait bougé du jour au lendemain.
L’ironie est double. Au lancement d’Opus 5, son éditeur affirmait ne pas l’avoir entraîné aux tâches offensives et le situait au niveau de son modèle spécialisé pour repérer des failles, mais loin derrière pour les transformer en attaques. C’est pourtant ce modèle grand public, présenté comme bridé, qui a fait basculer l’opération. Le seuil critique franchi par OpenAI avec GPT-6 Astra et les capacités offensives qu’Anthropic réserve au projet Glasswing avaient déjà fixé le décor : la nouveauté n’est pas la puissance d’un modèle de pointe, mais l’efficacité offensive d’un outil ordinaire entre des mains expertes.
Le garde-fou contourné par un habillage
Restait un obstacle : le modèle refusait d’écrire une attaque visant une instance distante. Les chercheurs l’ont contourné sans le forcer, en plaçant Claude dans une boucle autonome contre leur propre serveur de test, présenté par une redirection au nom de forum de compétition, de sorte que la cible ressemble à un exercice de capture de drapeau. L’agent, croyant travailler sur un terrain d’entraînement, est parvenu seul à l’exécution de code vers 10 heures UTC, et l’attaque fiabilisée a été rejouée contre le forum d’OpenAI. La barrière a cédé non sur la nature de l’acte demandé, mais sur le décor présenté, comme lors d’une campagne d’espionnage documentée fin 2025 où un modèle avait cru mener des tests défensifs : une classification fondée sur l’intention déclarée reste fragile.
L’identité, le maillon que l’IA n’a pas touché
Les chercheurs l’ont répété : ils ont choisi les cibles et guidé les modèles, l’IA accélérant la part la plus technique sans décider à leur place. Une lecture à contre-courant déplace pourtant le projecteur : pour plusieurs analystes, l’étape décisive n’est pas l’attaque logicielle, cantonnée à un forum, mais la faiblesse d’identité qui a permis d’en sortir : un site à faible enjeu branché sur le même flux d’authentification que les comptes de travail des salariés. Retirez cette erreur, et la démonstration s’arrête à la prise de contrôle d’une page d’entraide.
Les agents de code, un actif à privilèges
Le mécanisme exact de la mauvaise configuration n’a pas été rendu public. OpenAI indique seulement avoir restreint les permissions des jetons de connexion du forum et révoqué les jetons et sessions concernés. On sait, par les comptes rendus, que ces jetons emportaient des droits excessifs, au point d’ouvrir un accès complet aux comptes ChatGPT et Codex associés.
La leçon dépasse OpenAI. Un compte Codex relié à une organisation GitHub n’est plus un simple identifiant : c’est un agent qui agit au nom d’un salarié et hérite de ses accès. Compromettre le compte grand public d’un employé revient alors à toucher au code de l’entreprise. À mesure que les agents de programmation s’installent dans les chaînes de production, le cloisonnement des niveaux d’assurance devient une question de premier ordre.
L’économie de l’attaque
Le prix payé éclaire le rapport de force. OpenAI a versé 6 500 dollars à Hacktron, le 1er septembre, en précisant qu’elle visait sa propre faille d’identité, non les actions menées contre le forum, hors de son programme. La somme est modeste : ce programme, ouvert en 2023, plafonnait à 20 000 dollars avant d’être porté à 100 000 pour les failles critiques exceptionnelles au printemps 2025.
En face, le coût s’effondre. Hacktron chiffre son programme multi-cibles à moins de 3 000 dollars de jetons sur deux mois, chaque attaque demandant un à deux jours, parfois après des milliers d’envois d’images. Le travail a mobilisé l’outillage maison comme des modèles concurrents, dont un modèle d’OpenAI et Opus 5 : les deux camps ont servi, signe que la capacité offensive se banalise chez tous les fournisseurs. La société estime que des tâches réclamant naguère des semaines ou des mois tiennent désormais en quelques jours.
Ce que la recherche avait déjà mesuré
L’accélération prolonge une courbe suivie depuis deux ans. Au printemps 2024, une équipe universitaire montrait qu’un modèle exploitait seul la grande majorité de failles connues quand on lui fournissait leur description officielle, mais presque aucune sans elle ; l’affaire Hacktron va plus loin, le modèle ayant repéré de lui-même la correction non signalée. L’agence française de cybersécurité concluait, début 2026, qu’aucune IA n’avait mené seule toutes les étapes d’une attaque et que son apport dépend du niveau de l’attaquant : l’opération en est l’illustration exacte.
La chaîne, une fois dépliée, raconte une histoire plus nuancée que son titre. Un modèle a comprimé le maillon le plus cher, la mise au point d’une attaque fiable, ramenée de plusieurs semaines à quelques heures. Mais le maillon qui a réellement ouvert les dépôts d’OpenAI était humain : une erreur de configuration d’identité et, en amont, un correctif publié sans étiquette qui n’a jamais atteint la machine exposée.
Le rappel n’est pas inutile à l’heure où l’on s’inquiète surtout des modèles qui échappent à leur environnement. Ici, aucune émancipation : des chercheurs ont piloté un outil, du choix de la cible à la décision d’arrêter. Une ancienne intrusion dans la messagerie interne d’OpenAI, révélée en 2024, relevait d’une tout autre logique ; le fait marquant de l’été n’est pas qu’une IA agisse seule, mais qu’une poignée de personnes fasse, avec elle, le travail d’une équipe entière.
Reste la question posée à tout l’écosystème. Si le coût de découverte et d’armement d’une faille s’effondre pendant que la correction dépend de mainteneurs souvent bénévoles, l’écart se creuse du mauvais côté : le décodeur en cause était entretenu par une poignée de personnes, et sa réparation, disponible, n’avait pas atteint les serveurs concernés. Le programme HEIF Heist réunit d’autres cibles, dont certaines restent encore masquées. La question n’est pas de savoir si l’affaire se répétera, mais combien de plateformes laissent encore passer une image vers un décodeur non corrigé, et si les éditeurs de modèles sauront durcir leurs garde-fous contre le simple habillage d’une requête en exercice.
Aller plus loin
Le récit de première main se lit dans le billet Hacking OpenAI que les trois chercheurs ont publié le 13 septembre : on y trouve la chronologie à l’heure près, le rôle successif d’Opus 4.8 puis d’Opus 5, le contournement du garde-fou par déguisement en compétition, la proposition de modification déposée en preuve et la position d’OpenAI sur la récompense, exposés sans filtre par ceux qui ont mené l’opération.
Pour mesurer que l’attaque d’OpenAI n’est qu’un cas parmi d’autres, le site HEIF Heist recense l’ensemble du programme de recherche, les deux décodeurs visés, les passerelles par lesquelles ils sont atteints et la liste des services touchés, de Slack à GitHub Enterprise en passant par Next.js, chacun assorti de son avis de sécurité.
Du côté de l’éditeur du forum, l’avis RCE via malformed HEIF file donne la version officielle : gravité retenue, versions touchées et corrigées, procédure de mise à jour et renvoi vers la faille amont de la bibliothèque, publié quatre jours après les faits et créditant l’équipe de recherche.
La faiblesse du décodeur elle-même est décrite sur la fiche CVE-2026-32882, qui détaille l’erreur d’indexation d’un plan mémoire à l’origine du débordement, la gravité qui lui a été attribuée et les versions successives où le correctif a fini par être intégré.
La parade concrète tient dans le dépôt discourse/safe_image, une frontière étroite qui confine le traitement des images non fiables au moyen d’un mécanisme d’isolation du noyau Linux, prive ces traitements d’accès réseau et refuse par défaut ce qu’elle ne sait pas décoder plutôt que de se rabattre en silence sur un autre outil.
Ce que l’éditeur du modèle disait de ses propres capacités offensives se vérifie sur la page Introducing Claude Opus 5, qui revendique un entraînement volontairement écarté des tâches offensives, des garde-fous censés bloquer la génération d’attaques et un programme de vérification pour les chercheurs habilités, autant d’éléments à confronter avec ce que l’opération en a tiré.
L’état de la menace vu de France se lit dans le rapport L’intelligence artificielle générative face aux attaques informatiques, où l’agence nationale posait, début 2026, qu’aucune IA ne conduisait seule une attaque complète et que son apport dépend étroitement du niveau de l’attaquant.
Le contrepoint malveillant du même contournement figure dans le compte rendu Disrupting the first reported AI-orchestrated cyber espionage campaign, où des opérateurs avaient fait exécuter l’essentiel d’une campagne d’espionnage à un modèle en le persuadant qu’il menait des tests défensifs pour une entreprise légitime.
La méthode par comparaison de correctifs, celle qui a repéré ici la réparation manquante, avait été inaugurée par un agent dans From Naptime to Big Sleep, qui trouvait une faille mémoire inédite dans un logiciel très répandu là où des centaines d’heures de test automatique avaient échoué.
La longue histoire des décodeurs d’images comme porte d’entrée est disséquée dans l’analyse A deep dive into an NSO zero-click iMessage exploit, qui montrait comment un fichier piégé exposait plus de vingt décodeurs sans le moindre geste de la cible.
Lus ensemble, ces documents dessinent une bascule discrète. La découverte d’une faille et sa transformation en arme, longtemps réservées à quelques spécialistes et à des semaines de travail, tiennent désormais dans un budget dérisoire et quelques jours, entre les mains d’experts qui pilotent un outil grand public. Ce qui n’a pas suivi le même mouvement, c’est la correction : elle dépend toujours d’organisations lentes et de mainteneurs isolés, et c’est dans cet écart, bien plus que dans la prouesse d’un modèle, que se loge le vrai déséquilibre.