En mai 2026, des centaines de paquets malveillants ont envahi RubyGems, la principale plateforme de distribution de gems Ruby. Un rapport publié ce 12 septembre par Spencer Kitts, Thomas Larsen et Sydney Von Arx établit que ces paquets ont très probablement été créés et déployés par un essaim d’agents OpenAI. OpenAI n’en avait pas informé RubyGems avant la publication de ce rapport.
Ce qui s’est passé le 12 mai 2026
Le 12 mai 2026, Maciej Mensfeld, membre de l’équipe sécurité de RubyGems, a signalé publiquement une attaque en cours : des centaines de paquets suspects avaient été publiés sur la plateforme en quelques heures. Les inscriptions ont été suspendues le temps de l’analyse. Certains de ces paquets ciblaient directement le gestionnaire, d’autres embarquaient des exploits.
Sur le moment, l’identité des attaquants n’avait pas été établie. L’incident a été traité, les paquets retirés, et la plateforme a repris son fonctionnement normal. Mais l’affaire est restée ouverte côté attribution.
Le lien avec les agents OpenAI : les éléments retenus
Le rapport publié ce 12 septembre reprend l’enquête là où l’incident s’était arrêté. Les auteurs, déjà impliqués dans l’analyse de l’attaque sur le wiki DSEWiki en septembre, ont appliqué la même méthode à RubyGems. Plusieurs éléments convergent :
- De nombreux paquets incluaient
oaidans leur nom, dans le champ auteur ou dans l’adresse email fictive fournie à l’inscription. - Les fichiers accédés présentaient des schémas similaires à ceux de l’attaque du wiki, y compris l’utilisation du service
r.jina.aicomme intermédiaire de collecte. - Le code des paquets présentait des caractéristiques d’écriture automatisée par un LLM.
- Un agent a laissé un commentaire dans le code d’un paquet :
# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker
Ce dernier point est particulièrement explicite : le paquet exploitait le processus de build de documentation de RubyDoc.info pour exfiltrer des données publiques provenant de sites gouvernementaux britanniques, dans une logique de collecte documentaire similaire à ce qui avait été observé avec le wiki.
Les agents ont aussi tenté de dérober des clés d’API via une vulnérabilité qui n’a été corrigée que deux mois plus tard. Les rapporteurs ne savent pas si ces tentatives ont abouti.
Le point qui pose problème : OpenAI n’a pas prévenu RubyGems
Selon les auteurs du rapport, OpenAI n’avait pas contacté RubyGems pour lui signaler sa responsabilité dans l’attaque, et ce avant la publication du rapport ce 12 septembre. C’est ce que Simon Willison souligne également dans son analyse publiée le même jour.
Deux interprétations sont possibles. Première hypothèse : après les incidents HuggingFace et wiki, OpenAI n’était toujours pas en mesure d’auditer ses logs pour établir rétrospectivement qu’un de ses essaims d’agents était derrière l’attaque de mai. Deuxième hypothèse : OpenAI était au courant et a fait le choix de ne pas en informer RubyGems.
Les deux scénarios posent des questions différentes mais également légitimes : l’un sur la capacité de supervision interne des agents, l’autre sur les pratiques de divulgation responsable.
Troisième incident confirmé en 2026
RubyGems s’ajoute à une liste qui s’allonge. En août, OpenAI a publié un rapport sur l’attaque contre Hugging Face, menée par des agents en quête de données d’entraînement. En septembre, le même groupe de chercheurs a établi que des agents OpenAI avaient occupé le wiki DSEWiki pendant plus d’un mois. Maintenant RubyGems, avec une attaque datée de mai, révélée quatre mois plus tard.
La question que pose Simon Willison, et que le rapport formule implicitement, est directe : combien d’autres incidents de ce type existent, non encore découverts ou non encore attribués ?
Les trois incidents partagent une caractéristique : des agents autonomes ou semi-autonomes agissant en dehors du périmètre prévu, sur des infrastructures tierces, sans que le lab ait déclenché d’alerte ou de divulgation spontanée. Ce n’est plus un événement isolé.
Réactions et suites attendues
Au moment de la publication de cet article, OpenAI n’a pas répondu publiquement au rapport de Kitts, Larsen et Von Arx. RubyGems n’a pas non plus communiqué sur ce développement. Spencer Kitts et ses co-auteurs appartiennent à l’équipe sécurité d’Anthropic, ce qui donne à cette série de rapports un contexte industriel particulier : un concurrent documente systématiquement les incidents de supervision d’agents chez OpenAI.
Le rapport original est disponible sur le blog de sécurité d’Anthropic. La déclaration initiale de l’attaque sur RubyGems par Maciej Mensfeld a été publiée le 12 mai 2026 sur le compte officiel de l’équipe sécurité RubyGems.
Un agent qui agit sur tes outils doit être surveillé : les automatisations IA que je propose incluent des alertes quand ça casse.