Une équipe de chercheurs a pris le contrôle de comptes d’employés d’OpenAI en enchaînant deux failles distinctes : un défaut de traitement d’image dans une bibliothèque utilisée par ImageMagick, et une faiblesse de l’authentification unique reliant plusieurs services internes. L’exploit a été construit avec l’assistance de Claude Opus 5, utilisé comme copilote offensif pour accélérer l’analyse et l’enchaînement des vulnérabilités.
Une image HEIF comme point d’entrée
Le forum public d’aide d’OpenAI, hébergé sur Discourse, accepte les images au format HEIF et HEIC envoyées par les utilisateurs. Ces fichiers sont ensuite traités par ImageMagick, qui délègue le décodage à la bibliothèque libheif. Une faille de corruption mémoire dans cette bibliothèque permettait à une image spécialement construite de compromettre le serveur qui l’analysait, un scénario classique de désérialisation de contenu non fiable côté serveur.
Ce type de chaîne de traitement d’image reste un point aveugle fréquent : la conversion de formats exotiques est souvent déléguée à des bibliothèques tierces peu auditées, loin du code applicatif principal que l’équipe de sécurité surveille en priorité.
L’authentification unique, maillon faible de la chaîne
La compromission du serveur du forum n’aurait eu qu’un impact limité si elle n’avait pas ouvert l’accès à l’identité partagée utilisée par d’autres services OpenAI. Selon les chercheurs de Hacktron, le second défaut relevait moins d’un bug du logiciel de forum que d’un problème de conception : n’importe quel service, propriétaire ou tiers, branché sur le même fournisseur d’identité, aurait pu accorder le même niveau d’accès.
| Étape | Composant touché | Nature du défaut |
|---|---|---|
| 1 | Discourse → ImageMagick → libheif | Corruption mémoire au décodage d’une image HEIF forgée |
| 2 | Authentification unique OpenAI | Confiance excessive accordée à un service tiers connecté au même SSO |
| 3 | Compte ChatGPT / Codex d’un employé | Prise de contrôle de session via le SSO compromis |
| 4 | Dépôt GitHub interne | Ouverture d’une pull request via le lien Codex de l’employé |
Claude Opus 5 comme copilote offensif
Hacktron a utilisé Claude Opus 5 pour explorer la surface d’attaque et enchaîner les deux vulnérabilités plus rapidement qu’une analyse manuelle classique. Le modèle a servi à qualifier l’impact du défaut mémoire et à cartographier les services connectés au SSO, un travail habituellement long lorsqu’il est mené entièrement à la main. Les chercheurs précisent que la pull request déclenchée sur le dépôt interne n’a ni lu le code source, ni fusionné ni livré quoi que ce soit, et n’a touché aucune donnée client.
L’usage d’un modèle comme accélérateur de recherche en sécurité illustre une tendance déjà visible ailleurs dans l’outillage des équipes offensives et défensives, à mesure que ces mêmes agents autonomes gagnent en autonomie sur des tâches de production longues, bien au-delà du seul champ de la sécurité.
# Schéma simplifié d'un pipeline de conversion d'image côté serveur,
# le type de chaîne visé par la faille libheif
convert uploaded-image.heic -resize 800x800 -quality 85 output.jpg
identify -verbose uploaded-image.heic
OpenAI a corrigé la faille en quatorze heures après le signalement, un délai de réaction rare pour une chaîne d’authentification partagée entre plusieurs services.
Point de vigilance : tout service auto-hébergé qui délègue la conversion d’image à ImageMagick ou à une bibliothèque de décodage tierce (libheif, libraw, libwebp) hérite du niveau de sécurité de cette dépendance. Un socle de durcissement minimal inclut la mise à jour régulière de ces bibliothèques, indépendamment du cœur applicatif.
La réponse d’OpenAI et le calendrier de correction
OpenAI a confirmé un correctif environ quatorze heures après le rapport initial de Hacktron, puis a versé une prime de 6 500 dollars à l’équipe le 1er septembre. Le calendrier serré tranche avec la complexité de la chaîne : la faille touchait un composant tiers peu visible, et sa correction complète supposait de revoir la confiance accordée par le SSO à des services externes, pas seulement de corriger une ligne de code dans libheif. Le cas illustre aussi, en creux, les questions que pose l’arrivée de modèles de plus en plus autonomes dans la boîte à outils des équipes techniques, côté attaque comme côté défense.
Ce qu’il faut retenir
Une bibliothèque de décodage d’image tierce peut devenir la porte d’entrée d’une compromission qui dépasse largement le périmètre du service qui l’utilise, dès lors qu’une authentification unique partagée relie ce service à des systèmes plus sensibles. L’assistance d’un modèle comme Claude Opus 5 a raccourci le temps nécessaire pour qualifier et enchaîner ces deux défauts, sans modifier la nature du problème de fond : l’audit des dépendances de traitement de fichiers et la cartographie des services connectés au SSO restent les deux angles morts les plus coûteux à ignorer.
Ce type de chaîne rappelle qu’un audit de sécurité qui s’arrête au code applicatif laisse toujours une bibliothèque de conversion de fichiers hors du radar. Sur les infrastructures suivies en gestion courante, la mise à jour des dépendances de traitement d’image (ImageMagick, libheif, libwebp) est traitée avec la même priorité qu’un correctif du CMS lui-même, précisément parce que c’est le genre de composant qu’on oublie de lister — Simon Janvier.
Pour aller plus loin : le récit complet sur The Register.
