Trois Heures, Pas Trois Mois
Le 23 juillet, trois chercheurs en sécurité de Hacktron observaient un dépassement de tampon dans libheif, la bibliothèque qui décode les photos HEIC et HEIF. Ils avaient une théorie. Le forum communautaire d'OpenAI, community.openai.com, tournait sur Discourse. Le pipeline d'envoi de Discourse transmettait les formats d'image non reconnus directement à ImageMagick, lui-même dépendant de cette même libheif vulnérable. Claude Opus 4.8 a passé plusieurs sessions à tenter de transformer la théorie en exploit fonctionnel sans jamais franchir l'address space layout randomization. Les chercheurs ont mis le projet de côté.
Puis, dans la soirée du 24 juillet, Anthropic a publié Claude Opus 5. L'équipe a soumis au nouveau modèle le même problème. En trois heures, il disposait d'un exploit ARM64 fonctionnel pour un Mac local, puis l'a porté seul vers l'environnement de production x86-64 et jemalloc de Discourse. À 06h00 UTC le 25 juillet, l'exploit fonctionnait contre une cible locale. À 10h00 UTC, il fonctionnait contre le forum en direct d'OpenAI.
Le Bug Que Personne N'a Eu Besoin de Corriger Pour de Vrai
La faille libheif n'était pas une découverte. Elle avait déjà été corrigée en amont, discrètement, sans qu'un numéro CVE lui soit attribué. Pas de CVE signifiait aucune alerte pour l'équipe de sécurité de Debian, si bien que Debian 12, l'image de base de Discourse, n'a jamais récupéré le correctif. Discourse a hérité de la faille via ImageMagick. Le forum d'OpenAI en a hérité via Discourse. Trois organisations, trois décisions distinctes de ne pas agir, aucune fautive à elle seule.
La brèche du forum seule serait restée contenue. Ce qui en a fait un incident OpenAI, c'est une authentification unique reliant le forum aux comptes ChatGPT et Codex des employés. Compromettre un compte du forum a donné aux chercheurs une session qui menait jusqu'à Codex. Codex était relié à GitHub. GitHub hébergeait le monorepo openai/openai. Neuf composants, neuf équipes distinctes, un chemin continu d'une bibliothèque photo non corrigée jusqu'au code source.
À Quelle Vitesse la Chaîne S'est Vraiment Refermée
Hacktron a publié sa propre chronologie à la minute près. Mise bout à bout, l'écart entre un modèle incapable de finir la tâche et un modèle qui a traversé directement la frontière d'identité d'OpenAI tenait à une seule sortie de produit.
| Heure (UTC) | Événement | Acteur |
|---|---|---|
| 23 juil, 05h00-06h00 | Dépassement libheif identifié ; Opus 4.8 échoue à produire un exploit fiable | Humain + Opus 4.8 |
| 24 juil, soir | Claude Opus 5 publié ; reçoit la même cible | Anthropic |
| 25 juil, 06h00 | Exploit ARM64 fonctionnel confirmé sur un Mac local | Opus 5 |
| 25 juil, 10h00 | Exécution de code à distance obtenue sur Discourse Cloud, /etc/hosts lu | Opus 5, dirigé par des humains |
| 25 juil, 13h30-15h30 | Compte d'un employé atteint sur ChatGPT et Codex ; accès démontré, tests arrêtés | Chercheurs humains |
| 25 juil, 22h49 | OpenAI confirme le déploiement d'un correctif | OpenAI |
| 1 sep | OpenAI verse une récompense de 6 500 dollars pour la seule découverte SSO | OpenAI |
La construction de l'exploit en trois heures fait le titre. Ce qui mérite qu'on s'y attarde, ce sont les 22 heures et 49 minutes entre le moment où les chercheurs ont atteint un compte employé et celui où OpenAI a confirmé le correctif. C'est le véritable temps de réponse que la chaîne a mis à l'épreuve. Il a tenu.
Pourquoi Cela Compte pour Tout Opérateur dans l'UE, Pas Seulement les Laboratoires d'IA
La conclusion de Hacktron est sans détour : la sécurité s'est longtemps appuyée sur la complexité comme rempart, sur l'idée qu'un exploit exige une équipe bien dotée et des mois de délai. C'est précisément ce rempart qu'Opus 5 a fait tomber sur ce bug. Les chercheurs ont écrit qu'un travail qui exigeait auparavant une expertise rare peut désormais se comprimer en puissance de calcul. Ils ont ajouté que le saut d'Opus 5 vers le modèle suivant était déjà visible dans leurs propres tests.
Pour une entreprise soumise à NIS2, cette compression pèse sur l'horloge, pas seulement sur le budget. Les entités essentielles et importantes doivent signaler un incident significatif dans les 24 heures suivant sa découverte et déposer un rapport complet sous 72 heures. La chaîne de Hacktron, de l'exploit fonctionnel au dépôt interne compromis, s'est refermée dans cette même fenêtre de 72 heures. L'horloge de notification et celle de l'attaquant ne tournent plus à des vitesses différentes. Un processus de détection conçu en jours, et non en heures, est construit pour le mauvais adversaire.
L'Essentiel
Personne dans cette histoire n'a agi avec imprudence. OpenAI faisait tourner un programme de récompense et a payé en quelques jours. Hacktron a divulgué de manière responsable et s'est arrêté dès que l'accès a été démontré. Discourse a livré un correctif sous 48 heures après le signalement. Le système a fonctionné exactement comme conçu. Un modèle d'IA a quand même atteint le code source d'un laboratoire d'IA de premier plan, en partant d'un bug de téléversement de photo déjà corrigé ailleurs sur internet.
Les propres conditions du programme d'OpenAI excluaient les tests contre Discourse lui-même, si bien que le versement de 6 500 dollars n'a couvert que la faille de frontière d'identité, pas l'exploit qui a ouvert la porte aux chercheurs. Cet écart entre ce que couvre un programme de récompense et ce dont un attaquant a vraiment besoin mérite un audit à part entière, assisté par un modèle ou non.
À lire ensuite: Votre modèle de menace NIS2 visait le mauvais attaquant | Les meilleurs outils d'IA de piratage sont désormais réservés sur invitation
