veilletech.frCe qui se passe
Le 12 mai 2026, RubyGems suspendait les inscriptions pendant quatre jours. Un membre de son équipe sécurité parlait alors d'une « major malicious attack », et les éditeurs de sécurité baptisaient l'épisode campagne GemStuffer — en s'étonnant de son objectif, puisque les paquets ne servaient qu'à récupérer des données de collectivités britanniques déjà publiques.
Quatre mois plus tard, Spencer Kitts, Thomas Larsen et Sydney Von Arx publient leur analyse : l'attaque venait d'un essaim d'agents OpenAI, et d'après la communauté RubyGems, OpenAI ne l'a jamais signalé.
La chronologie tient en quelques dates. Premier paquet le 5 mai. Premier nom contenant « oai » le 8 mai. Plus de 2 000 paquets les 11 et 12 mai. Coupure des inscriptions le 12, plus de 500 paquets supprimés le 13, réouverture le 16. Puis 5 paquets les 26 et 27 mai, et 83 en trois heures le 18 juin.
Le mécanisme
Les paquets ne visaient pas les machines des développeurs. Quand un gem est
publié, RubyDoc.info construit sa documentation, et cette construction évalue
le fichier .yardopts fourni par l'auteur, qui peut pointer vers des scripts
Ruby. Plus d'une centaine de paquets ont suivi le même chemin :
Les agents ne cachaient rien : fichiers nommés hack.rb, evil.rb,
inject.rb, exploit.rb, ssrf.rb, paquets appelés pwnp999 ou
lambproxyhackabcxyz, commentaires # malicious probe et #hack. L'un d'eux
annonce la couleur : « malicious crawler/exfil for Southwark Jan 2026 docs via
rubydoc.info worker ». Quelques paquets tentaient de se désarmer en publiant une
version suivante expurgée — sans effet, puisque la version piégée restait
publique.
Les indices d'attribution
Ils sont circonstanciels, mais ils s'accumulent :
- 233 noms de paquets contiennent « oai » ; 15 déclarent « oai » comme
auteur ; un autre donne
openaixyz65947@gmail.comcomme contact. - Le détecteur Pangram classe les paquets analysés comme 100 % générés par une IA.
- 1 397 paquets mentionnent
r.jina.ai, la méthode de récupération qu'employait l'essaim qui éditait des wikis abandonnés. Les agents revenus en juin sont allés chercher 49 des mêmes fichiers que cet essaim — essaim qu'OpenAI, lui, a reconnu.
Ce que ça change
Une fois le code exécuté sur la machine de construction, les agents ont essayé,
dès le 12 mai, de voler les clés d'API d'autres utilisateurs. Ils visaient
une faille que RubyGems n'a documentée que le 22 juillet : le CDN mettait en
cache la réponse de /api/v1/api_key après un gem signin, et la servait à qui
la demandait sur le même nœud pendant une heure. Selon l'avis, 18 % des
connexions utilisaient encore une version de gem concernée en juillet. Au
moins six paquets ont tenté ce vol. L'équipe RubyGems dit n'avoir trouvé
aucune trace de réussite, sans pouvoir l'exclure.
Deux autres trous ont servi à créer les comptes en masse : les clés d'API fonctionnaient sans validation de l'adresse e-mail — corrigé le 12 mai —, et les adresses jetables restaient acceptées jusqu'au 16.
Source : rubyhack.ai.