Piratage d'OpenAI avec Claude : ce que révèle l'IA offensive pour les entreprises

TL;DR.

Trois chercheurs indépendants en sécurité, réunis au sein de l'équipe Hacktron, ont pris le contrôle de comptes employés d'OpenAI en moins de 72 heures en utilisant Claude, le modèle d'Anthropic. Le point d'entrée n'était pas une infrastructure développée par OpenAI, mais Discourse, le service tiers qui héberge son forum communautaire. L'épisode illustre un basculement dans la manière dont les intrusions informatiques se préparent et s'exécutent, et désigne le maillon faible le plus banal des systèmes d'information d'entreprise : le prestataire externe.

Les chercheurs ont utilisé Claude dans ses versions Opus 4.8 et 5 pour identifier et exploiter les vulnérabilités. Après avoir pris la main sur des comptes d'employés, ils ont atteint le dépôt GitHub interne d'OpenAI, baptisé « Monorepo », décrit comme contenant les « secrets algorithmiques » de l'entreprise. Ils se sont arrêtés avant de consulter le code lui-même et ont prouvé leur accès en envoyant une pull request depuis le compte Codex d'un employé, avant de signaler les failles. L'opération a duré moins de 72 heures, contre une cible parmi les plus exposées et les mieux surveillées du secteur technologique, avec une équipe de trois personnes.

Trois chercheurs indépendants en sécurité, réunis au sein de l'équipe Hacktron, affirment avoir pris le contrôle de comptes employés d'OpenAI en moins de 72 heures. Leur outil principal : Claude, le modèle d'Anthropic, dans ses versions Opus 4.8 et 5. Ils sont allés jusqu'à accéder au dépôt de code interne d'OpenAI, avant de signaler les failles. Cet épisode n'est pas une anecdote de rivalité entre laboratoires d'IA : il documente un basculement concret dans la manière dont les intrusions informatiques se préparent et s'exécutent, et il désigne le maillon faible le plus banal des systèmes d'information d'entreprise, le prestataire externe.

Ce qui s'est passé, fait par fait

Selon les informations publiées, l'équipe a utilisé Claude pour identifier et exploiter des vulnérabilités dans les systèmes liés à OpenAI. Le point d'entrée n'était pas une infrastructure développée par OpenAI, mais Discourse, le service tiers qui héberge son forum communautaire. Une fois cette brèche ouverte, les chercheurs ont réussi à prendre la main sur des comptes d'employés.

Ils ont ensuite atteint le dépôt GitHub interne d'OpenAI, baptisé « Monorepo », décrit par des sources citées dans l'enquête comme contenant les « secrets algorithmiques » de l'entreprise. Point important sur le plan déontologique : les chercheurs se sont arrêtés avant de consulter le code interne lui-même. Pour prouver leur accès sans exfiltrer quoi que ce soit, ils ont envoyé une pull request (une proposition de modification de code) depuis le compte Codex d'un employé. Les failles ont ensuite été signalées.

La durée totale de l'opération, moins de 72 heures, est le chiffre qui mérite d'être retenu. Il s'agit d'une cible parmi les plus exposées et les mieux surveillées du secteur technologique, attaquée par une équipe de trois personnes.

Pourquoi l'usage d'un modèle d'IA change l'équation

La recherche de vulnérabilités a longtemps été une activité artisanale, lente et coûteuse en compétences rares. Elle suppose de lire beaucoup de code, de comprendre des architectures inconnues, de tester des hypothèses une par une. C'est précisément le type de travail que les modèles de langage récents accélèrent : lecture massive, génération d'hypothèses, production de code d'exploitation.

Ce cas illustre donc moins une faille d'OpenAI qu'un déplacement du rapport coût/efficacité de l'attaque. Ce qui demandait une équipe expérimentée et plusieurs semaines peut désormais se compresser en quelques jours. Le raisonnement vaut évidemment dans les deux sens : les mêmes capacités servent aux équipes défensives pour auditer leur propre périmètre. Mais la défense doit couvrir l'ensemble de la surface d'attaque, quand l'attaque n'a besoin que d'un point d'entrée.

Le vrai sujet : la chaîne de dépendances externes

L'élément le plus transposable de cette affaire est l'origine de l'intrusion. Un forum communautaire hébergé par un prestataire n'est, dans la plupart des cartographies de risques, pas classé comme critique. Il ne contient ni données clients sensibles, ni propriété intellectuelle. Il est pourtant devenu le premier domino.

Le mécanisme est classique et il concerne toutes les entreprises, quelle que soit leur taille : un outil périphérique partage des identités avec des outils centraux. Un compte compromis sur un service secondaire devient une identité valide ailleurs, par réutilisation de mot de passe, par authentification unique mal cloisonnée, ou par jetons d'accès trop permissifs. La plupart des organisations utilisent aujourd'hui des dizaines de services SaaS dont aucun n'est audité avec la même rigueur que le système d'information principal.

Ce que ça change pour vous

Quelques actions concrètes découlent directement de ce cas, sans qu'il soit nécessaire d'être une entreprise technologique.

• Inventorier les services tiers connectés à vos identités. Forums, outils de support, plateformes marketing, espaces de documentation : tout ce qui utilise les comptes de vos collaborateurs fait partie de votre surface d'attaque, même si ce n'est pas vous qui l'hébergez.
• Cloisonner les identités. Un compte utilisé sur un service périphérique ne devrait jamais ouvrir l'accès aux dépôts de code, aux environnements de production ou aux données clients. L'authentification unique est un confort, pas une mesure de sécurité si elle n'est pas assortie de périmètres distincts.
• Auditer les jetons et les droits des outils d'IA connectés. Les assistants de développement et les intégrations diverses détiennent souvent des droits d'écriture sur des dépôts. Dans ce cas précis, c'est un compte lié à un assistant de code qui a servi à démontrer l'accès.
• Considérer que le délai de réaction s'est raccourci. Si une intrusion peut se construire en trois jours, les cycles de correctifs mensuels et les revues de sécurité annuelles ne sont plus calibrés sur le bon rythme.

La divulgation responsable reste la norme, pour l'instant

Il faut souligner ce que cette équipe n'a pas fait : elle n'a pas lu le code interne, n'a rien exfiltré, et a signalé les vulnérabilités. C'est le cadre de la divulgation responsable, qui structure une grande partie de la recherche en sécurité depuis des années.

Cette retenue est le fait de chercheurs qui ont choisi de la pratiquer. Les capacités techniques qu'ils ont démontrées ne sont pas, elles, conditionnées à cette éthique. C'est ce qui rend l'exercice instructif : il donne une mesure publique et datée de ce qui est devenu possible, avec des outils accessibles commercialement.

Une question de gouvernance, pas seulement d'outillage

Pour un comité de direction, la leçon n'est pas d'interdire les modèles d'IA, ni de considérer qu'un outil est en soi dangereux. Elle est plus prosaïque : la sécurité d'une organisation se mesure à son point le plus faible, et ce point est de plus en plus souvent situé en dehors de ses murs, chez un prestataire dont personne ne relit le rapport d'audit.

La question à poser en interne n'est pas « utilisons-nous l'IA de manière sécurisée ». Elle est plutôt : combien de services externes détiennent aujourd'hui une identité valide de nos collaborateurs, et qui, dans l'entreprise, en tient la liste à jour ?

Questions fréquentes

Qui a piraté les comptes employés d'OpenAI ?

Trois chercheurs indépendants en sécurité, réunis au sein de l'équipe Hacktron. Ils ont signalé les failles après les avoir exploitées, sans exfiltrer de code interne.

Combien de temps a duré l'opération ?

Moins de 72 heures. C'est le chiffre qui mérite d'être retenu, puisqu'il s'agit d'une cible parmi les plus exposées et les mieux surveillées du secteur technologique, attaquée par une équipe de trois personnes seulement.

Comment les chercheurs sont-ils entrés dans les systèmes d'OpenAI ?

Le point d'entrée n'était pas une infrastructure développée par OpenAI, mais Discourse, le service tiers qui héberge son forum communautaire. Une fois cette brèche ouverte, ils ont pris la main sur des comptes d'employés, puis atteint le dépôt GitHub interne baptisé « Monorepo ».

Quel outil d'IA a été utilisé pour trouver les failles ?

Claude, le modèle d'Anthropic, dans ses versions Opus 4.8 et 5. L'équipe s'en est servie pour identifier et exploiter des vulnérabilités dans les systèmes liés à OpenAI.

Comment les chercheurs ont-ils prouvé leur accès sans voler de données ?

Ils se sont arrêtés avant de consulter le code interne lui-même. Pour démontrer leur accès sans rien exfiltrer, ils ont envoyé une pull request, c'est-à-dire une proposition de modification de code, depuis le compte Codex d'un employé.