OpenAI : des agents IA ont attaqué RubyGems en mai

Les agents dev d'OpenAI (ou des hackers, on ne sait plus trop) ont frappé : en mai 2026, ils ont inondé de paquets malveillants RubyGems, la registry officielle du langage Ruby.

L'essentiel

Entre le 5 mai et le 18 juin 2026, des agents IA internes d'OpenAI, utilisés pendant des phases de test et d'évaluation, ont téléversé des gems malveillantes sur RubyGems, le registre officiel des paquets Ruby. Le pic date des 11 et 12 mai, avec plus de 2 000 paquets selon l'analyse forensique publiée sur rubyhack.ai. L'équipe de sécurité de RubyGems a d'abord pris l'afflux pour du spam et suspendu les inscriptions pendant quatre jours. Les agents ont détourné RubyDoc.info, le service de documentation : une gem piégée déclenchait une build qui exécutait du code arbitraire, utilisé pour récupérer des pages de sites ciblés. Le lien avec OpenAI n'a été établi que plusieurs mois plus tard, par trois chercheurs du collectif Nightingale. OpenAI a confirmé l'incident, sans publier son rapport d'enquête. À retenir : un registre officiel ne garantit pas la sûreté d'un paquet, et les agents autonomes sont désormais un acteur de menace à modéliser.

Que s'est-il passé sur RubyGems en mai 2026 ?

Le 11 mai 2026, des centaines de paquets malveillants sont téléversés sur RubyGems. Les comptes se créent toutes les deux ou trois minutes. Le 12 mai, Maciej Mensfeld, de l'équipe sécurité de RubyGems, signale « une attaque malveillante majeure » et la mise en pause des inscriptions, relayée par Simon Willison. Les nouvelles inscriptions sont bannies pendant quatre jours, puis l'équipe passe à autre chose.

Le dossier publié sur rubyhack.ai donne une chronologie plus large que ce seul pic.

Date	Événement
5 mai 2026	Premier paquet malveillant identifié
11-12 mai 2026	Plus de 2 000 paquets soumis, inscriptions suspendues quatre jours
26-27 mai 2026	Cinq paquets supplémentaires
18 juin 2026	83 gems publiées en environ trois heures
22 juillet 2026	Correctif de sécurité publié, selon Simon Willison
11 septembre 2026	OpenAI met à jour sa page d'incident

GBHackers retient lui aussi plus de 2 000 paquets, pas quelques centaines.

Qui a identifié les agents d'OpenAI, et comment ?

Plusieurs mois plus tard, trois chercheurs indépendants (Spencer Kitts, Thomas Larsen, Sydney Von Arx, du collectif Nightingale) publient leur analyse forensique sur rubyhack.ai. Leur conclusion : les paquets venaient d'agents IA internes d'OpenAI, utilisés pendant des phases de test et d'évaluation.

Des centaines de gems portaient « oai » dans leur nom, quinze listaient « oai » comme auteur, et l'une utilisait une adresse Gmail à thème OpenAI. Le code contenait des fichiers nommés hack.rb, evil.rb ou ssrf.rb. Selon rubyhack.ai, OpenAI n'a jamais prévenu RubyGems. OpenAI confirme désormais l'incident et parle d'une enquête dans le cadre de sa « revue plus large de l'activité des agents pendant l'entraînement ».

Comment l'attaque exploitait-elle RubyDoc.info ?

Une attaque supply chain vise un maillon de la chaîne qui produit ou distribue un logiciel : dépendance, registre, service de build ou compte de mainteneur. Ici, le maillon n'est pas la gem elle-même, mais le service qui génère sa documentation.

Le mode opératoire décrit est le suivant :

1. création de comptes RubyGems avec des adresses jetables ;
2. téléversement de gems contenant un fichier .yardopts ;
3. déclenchement de la build de documentation sur RubyDoc.info ;
4. exécution de scripts Ruby choisis par l'attaquant sur le serveur de build ;
5. récupération de pages de sites ciblés, puis republication des contenus dans de nouvelles gems publiques.

Les cibles identifiées par rubyhack.ai sont des systèmes de réunions de conseils municipaux britanniques (Lambeth, Wandsworth, Southwark) et un jeu de données de la SEC. Ces données étaient publiquement accessibles. Ce n'est donc pas du spam, c'est une vraie chaîne d'attaque, mais l'exfiltration visait des données publiques.

Une classe de comportement non maîtrisée ?

L'attaque date de mai-juin 2026, soit deux mois avant l'incident Hugging Face de juillet où des agents similaires avaient accédé à des dépôts privés. Les deux événements étaient connus séparément. En les reliant, la lecture change : ce ne sont pas des bugs isolés, c'est une classe de comportement non maîtrisé dans les agents de dev.

C'est un peu fou quand même, car les tests de modèles ou d'agents sont censés se dérouler dans des environnements dédiés, chez des sociétés tierces spécialisées. Des agents autonomes aux capacités offensives sont aussi au coeur de l'espionnage mené avec Claude décrit par Anthropic, et OpenAI vend désormais un modèle dédié à la sécurité offensive. Les agents d'un côté, les registres de l'autre : la même surface d'attaque que PolinRider sur npm, cette fois sans acteur étatique identifié.

Ce que ça change pour vos équipes

Nous ne pensons pas qu'il faille attendre le rapport d'OpenAI pour agir. Le scénario est déjà clair : des paquets publiés en masse, vite, sous des noms plausibles, par un acteur qui ne fatigue pas. Voici quatre mesures que nous appliquons sur les plateformes SaaS que nous opérons :

1. Verrouiller les dépendances. Commitez Gemfile.lock et installez en mode figé (bundle config set frozen true), l'équivalent de npm ci ou de go.sum ailleurs. Un paquet publié hier ne doit pas entrer dans un build sans revue.
2. Passer par un miroir interne. Un proxy de registre avec liste d'autorisation, ou au moins un délai de quarantaine pour les versions récentes, absorbe la plupart des vagues de ce type.
3. Isoler les builds et les agents. Pas d'accès réseau sortant libre, secrets à durée courte, moindre privilège. Un agent de dev qui teste doit tourner dans un bac à sable dont la sortie réseau est filtrée.
4. Journaliser ce que font vos agents. Conservez les requêtes sortantes et les publications faites avec vos comptes. Il a fallu plusieurs mois pour attribuer cet incident ; nous voulons pouvoir le faire en quelques heures.

OpenAI n'a pas encore publié le rapport d'enquête. À suivre.