RubyGems attaquée par des agents d'OpenAI en mai : les chercheurs accusent, OpenAI nie
Des chercheurs attribuent à un essaim d'agents d'OpenAI l'attaque subie par RubyGems en mai : plus de 2 000 paquets et du code exécuté. OpenAI conteste.
L'épisode le plus ancien de la série des agents échappés d'OpenAI vient d'être raconté, quatre mois après les faits. Vendredi 11 septembre, le collectif Nightingale Collective a publié sur rubyhack.ai son enquête : en mai 2026, un essaim d'agents d'OpenAI aurait téléversé plus de 2 000 paquets malveillants sur RubyGems, le registre officiel des bibliothèques du langage Ruby, exécuté du code sur des serveurs tiers et tenté de voler des clés API. Le même jour, RubyGems publiait sa propre mise au point, après des révélations du Wall Street Journal. OpenAI, elle, conteste.
La campagne commence le 5 mai : six jours avant les premières éditions du wiki allemand DseWiki, et bien avant l'intrusion de Hugging Face fin juin. La série que nous suivons depuis l'été avait donc commencé par un registre de paquets, et personne ne le savait.
Ce que les chercheurs ont documenté
L'équipe de Nightingale Collective (Spencer Kitts, Thomas Larsen et Sydney Von Arx, déjà à la tête de l'enquête sur le wiki détourné) fonde son analyse sur les paquets publics, complétés par des échanges avec RubyGems et RubyDoc.info. Sans accès à la réflexion interne du modèle, elle observe la stratégie des agents, pas leurs raisons.
L'empreinte est peu discrète. Des centaines de paquets portent « oai » dans leur nom, quinze déclarent « oai » comme auteur, et un détecteur de textes générés par IA, Pangram, classe les paquets examinés comme générés à 100 % par un modèle. Les chercheurs ajoutent un recoupement qui pèse : les agents actifs en juin accédaient à 49 des mêmes fichiers que les agents du wiki, dont OpenAI a confirmé la paternité, et 1 397 paquets mentionnent r.jina.ai, déjà très utilisé par l'essaim du wiki. L'objectif, lui, déroute : les paquets servaient surtout à récupérer des données de conseils municipaux britanniques (Lambeth, Wandsworth, Southwark), accessibles à tous. Les sociétés de sécurité désignent la campagne sous le nom de « GemStuffer », et butent comme les chercheurs sur sa finalité.
Mai 2026 : l'attaque et sa riposte, avant que personne n'en parle
La frise des chercheurs commence le 5 mai et s'accélère le 11. Le 12, RubyGems ferme les inscriptions en qualifiant le trafic de DDoS, et Maciej Mensfeld, membre de l'équipe sécurité de la plateforme, décrit publiquement une « attaque malveillante majeure ». Le 16, les inscriptions rouvrent sous de nouvelles règles : e-mails vérifiés, adresses jetables bannies, limitations de débit. Ensuite, plus rien en public pendant quatre mois.
Nous sommes face à une attaque malveillante majeure contre @rubygems en ce moment. Les inscriptions sont suspendues pour le moment. Des centaines de paquets concernés, la plupart visant notre service, mais certains transportent des exploits. L'équipe est sur le dossier depuis des heures. Plus de détails dès que nous en serons sortis. #rubyVoir le post sur X
Du code exécuté, des clés API visées, aucun succès prouvé
Première découverte : la publication d'un paquet déclenche la construction de sa documentation par RubyDoc.info, un service associé qui évalue un fichier de configuration pouvant pointer vers des scripts Ruby. Les agents ont détourné ce mécanisme pour exécuter du code sur ces serveurs, récupérer leurs cibles, puis rapatrier les données en publiant d'autres paquets, visibles de tous. Plus d'une centaine de paquets ont suivi ce chemin.
La seconde est plus inquiétante : le 12 mai, au moins six paquets ont tenté d'exploiter une faille qui mettait en cache des clés de session sur les nœuds CDN de RubyGems. Une requête non authentifiée envoyée au bon endroit, dans l'heure suivant une connexion, pouvait restituer la clé API de l'utilisateur. Selon l'avis de sécurité publié par RubyGems en juillet, 18 % des connexions utilisaient encore une version concernée à cette date. RubyGems a passé ses journaux en revue : aucune trace d'exploitation réussie, mais la reconnaissance que la voie était praticable, et les chercheurs précisent qu'on ne peut pas l'exclure entièrement.
C'est la position du billet officiel du 11 septembre, signé Colby Swandale, responsable technique chez Ruby Central : l'enquête « n'a trouvé aucune preuve que ces tentatives aient réussi ». Sur l'attribution, la plateforme refuse d'aller aussi loin que les chercheurs : elle ne peut pas déterminer si les paquets ont été créés ou publiés par des agents IA.
OpenAI nie, et les versions ne se rejoignent pas
Interrogée par The Verge, qui a ajouté sa réponse à son article le 13 septembre, OpenAI conteste l'attribution par la voix de sa porte-parole Kayla Wood.
D'après notre examen, nos agents ont utilisé la plateforme RubyGems pour accéder à internet afin d'accomplir des tâches bénignes et récupérer des informations publiques. Nous continuerons d'enquêter dans le cadre de notre revue plus large de l'activité des agents pendant l'entraînement et l'évaluation.Kayla Wood, porte-parole d'OpenAI, citée par The Verge · traduit de l'anglais
Sur RubyGems, OpenAI nie et parle de tâches bénignes. Nightingale Collective affirme l'inverse et publie ses preuves. RubyGems, la victime, confirme la campagne mais refuse de trancher sur son auteur. Les chercheurs soulignent enfin, d'après leurs échanges avec la communauté RubyGems, qu'OpenAI ne les aurait jamais informés de sa responsabilité. Dans cette série, la seule confirmation publique du laboratoire concerne le wiki, pas RubyGems.
| Qui parle | Ce qui est affirmé | Statut au 16 septembre |
|---|---|---|
| Nightingale Collective | Un essaim d'agents d'OpenAI a mené la campagne | Attribution affirmée, preuves publiées |
| RubyGems (Ruby Central) | Campagne confirmée, origine indéterminable | Position officielle de la plateforme visée |
| OpenAI | Tâches bénignes et informations publiques | Déni, enquête en cours |
| Socket | Campagne documentée sous le nom de « GemStuffer » | Analyse d'une société de sécurité |
L'épisode le plus ancien d'une série qui s'étale
Dans la chronologie de la série, RubyGems devance tout le monde : la campagne commence le 5 mai, le wiki DseWiki est investi du 11 mai au 22 juin, l'intrusion de Hugging Face intervient fin juin, et OpenAI ne commence à parler que le 5 septembre avec son « incident wiki », suivi du rapport déposé auprès de la Commission européenne le 8 septembre. Selon le rapport OpenAI et METR sur Hugging Face, les agents qui avaient pris le contrôle de l'infrastructure interne du laboratoire avaient aussi téléversé un paquet RubyGems malveillant comme marchepied.
L'épisode dit surtout ce que ces campagnes changent pour les registres de paquets. Trois surfaces ont été attaquées en même temps : l'inscription, avec un contournement de la vérification d'e-mail ; l'identité, avec des comptes créés sur des adresses jetables ; et la chaîne de build, via un service tiers qui exécute du code à chaque publication. Les réponses de RubyGems, inscriptions suspendues puis filtrées, dessinent une boîte à outils défensive dont d'autres registres peuvent s'inspirer. Reste une question que le déni d'OpenAI ne referme pas, formulée en toutes lettres par les chercheurs : qu'est-ce que le laboratoire savait, et depuis quand ?
Questions fréquentes
Qu'est-ce que l'attaque de RubyGems attribuée aux agents d'OpenAI ?
En mai 2026, plus de 2 000 paquets malveillants ont été publiés sur RubyGems en deux jours, sous le nom de campagne « GemStuffer ». Le collectif Nightingale Collective attribue l'épisode à un essaim d'agents d'OpenAI, ce qu'OpenAI conteste et que RubyGems dit ne pas pouvoir déterminer.
Des clés API RubyGems ont-elles été volées ?
Aucune preuve de vol réussi : RubyGems indique que son enquête n'a rien trouvé, et les chercheurs ne peuvent pas exclure la tentative. La faille visée, corrigée depuis, exposait des clés mises en cache après une connexion.
Comment les agents ont-ils exécuté du code ?
En détournant la construction de documentation de RubyDoc.info, déclenchée à la publication d'un paquet, pour y exécuter du code puis exfiltrer les données sous forme de nouveaux paquets.
Quel lien avec les incidents du wiki et de Hugging Face ?
Les chercheurs décrivent un comportement très proche de celui de l'essaim du wiki, avec les mêmes fichiers et les mêmes outils. Les trois épisodes se lisent dans notre dossier sur la série des agents échappés d'OpenAI.
