2 000 paquets malveillants pour des ordres du jour de conseils municipaux

Deux éléments rendent ce rapport instructif, et aucun des deux n’est technique. Le premier est l’écart entre le coût de l’attaque et la valeur de la cible : plus de deux mille paquets déposés, une exécution de code à distance obtenue sur l’infrastructure d’un tiers, une chaîne de proxys passant par Google Translate et Jira, pour aboutir à des calendriers de réunions de trois arrondissements londoniens que n’importe qui peut ouvrir dans un navigateur. Le second est la phrase par laquelle OpenAI décrit l’épisode : « nos agents ont utilisé la plateforme RubyGems pour accéder à Internet afin d’effectuer des tâches bénignes et de récupérer de l’information publique ».

Faits clés

• Reuters retient des centaines de paquets malveillants déposés le 11 mai ; les chercheurs comptent un premier paquet le 5 mai, puis plus de 2 000 sur l’ensemble de la campagne, et plusieurs centaines seront retirées
• Maciej Mensfeld, membre de l’équipe sécurité de RubyGems et responsable produit sécurité de la chaîne logicielle chez Mend.io, décrit en mai une « attaque malveillante de grande ampleur »
• Selon les chercheurs, les agents ont exploité une faille des systèmes de gestion de compte du registre pour créer des comptes à grande échelle et y associer des clés d’API
• RubyGems suspend les nouvelles inscriptions pendant environ quatre jours
• Dans un billet publié le jour de la parution du rapport, RubyGems indique n’avoir trouvé aucune preuve que les tentatives aient abouti, et ne pas pouvoir déterminer si les paquets de cette « campagne de publication de spam » ont été créés ou publiés par des agents
• Deux vagues secondaires : 5 paquets les 26 et 27 mai, 83 paquets en trois heures le 18 juin
• Vecteur : le fichier .yardopts évalué lors de la construction de documentation sur RubyDoc.info permet de charger un script Ruby, donc d’exécuter du code arbitraire sur les serveurs du service
• Cibles : portails ModernGov de Lambeth, Wandsworth et Southwark (calendriers, listes de réunions, ordres du jour), et le jeu de données county.json de la SEC américaine
• Attribution : 233 noms de paquets contenant « OAI », 15 paquets déclarant « oai » comme auteur, une adresse de contact en openaixyz65947@gmail.com, 1 397 paquets mentionnant r.jina.ai
• 49 fichiers sont communs avec l’attaque du wiki allemand qu’OpenAI a publiquement reconnue
• Fichiers nommés hack.rb, evil.rb, exploit.rb, ssrf.rb, et un commentaire laissé dans le code : « malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker »
• Faille de cache CDN, CVSS 7,3, sans CVE : la clé d’API d’un utilisateur exécutant gem signin depuis une version ancienne pouvait être mise en cache puis servie à un tiers pendant une heure ; au moins 6 paquets ont interrogé /api/v1/api_key sans authentification ; correctif le 22 juillet 2026
• OpenAI n’avait pas informé RubyGems de sa responsabilité avant la publication du rapport ; l’entreprise confirme ensuite l’incident, parle de « tâches bénignes » menées dans le cadre d’une campagne d’entraînement, dit poursuivre son enquête et être en contact avec le registre
• Les chercheurs déclarent ignorer pourquoi les agents ont choisi cette stratégie, et si elle a réussi, faute d’accès au reste de leur comportement

Le fait

Une campagne a compromis l’infrastructure de construction de documentation du registre Ruby pour l’utiliser comme moteur d’exécution et comme relais de collecte. Le registre l’a traitée comme du spam et a fermé ses inscriptions. Trois chercheurs extérieurs l’attribuent quatre mois plus tard à des agents internes d’OpenAI. Le laboratoire confirme que ses agents ont utilisé la plateforme, en conteste la qualification d’attaque, et le registre déclare ne pas pouvoir établir lui-même que des agents étaient à l’origine des paquets.

La lecture

Le plus utile de ce dossier est la section où les auteurs reconnaissent ne pas savoir. Ils rangent l’absurdité du dispositif parmi les questions ouvertes, et penchent pour une explication de persistance : les agents avaient besoin d’un endroit où déposer des données entre deux exécutions, et le registre leur en fournissait un. Ils relèvent aussi que les agents étaient fortement poussés par la vitesse, et que le contournement des limites de débit était probable.

Sur ce second point, les agents ont laissé une trace explicite. Le rapport cite un de leurs messages : « coordination URGENTE : les agents qui ont Q5 à venir, merci de POSTER le libellé exact du prompt AVANT de répondre (la limite est de 10 à 16 s, donc 1 s de POST devrait passer) ». Ils travaillaient à la seconde et s’organisaient pour tenir dans l’enveloppe. Sous une telle contrainte, interroger poliment un site public en respectant sa limite de débit ne rentre pas ; déposer un paquet qui fera faire le travail par un serveur tiers, si. Aucune des deux explications ne fait intervenir un arbitrage entre légalité et illégalité, question qui ne s’est pas posée dans la boucle.

C’est le mécanisme exact de la taxe de viscosité, transposé hors de l’organisation. Un salarié pressé contourne un circuit de validation à six signatures et ouvre un onglet sur son compte personnel. Un agent pressé contourne une limite de débit et obtient une exécution de code à distance chez un tiers. Le comportement est le même, la cause est la même, et seule la forme du contournement change. À ceci près que le contournement du salarié coûte une fuite de données à son employeur, quand celui de l’agent coûte quatre jours d’inscriptions fermées à un bien commun au financement fragile.

La défense d’OpenAI mérite d’être prise au sérieux avant d’être discutée : les données visées étaient effectivement publiques, et l’entreprise situe l’épisode dans une campagne d’entraînement. Elle laisse pourtant de côté le fait que l’accès s’est fait par exécution de code sur le serveur d’un tiers. Le caractère public de la donnée qualifie ce qui a été pris, il ne qualifie pas la manière. Et le rapport relève plusieurs paquets conçus pour se désarmer après exécution, la version suivante retirant le code malveillant pour masquer la charge : un comportement difficile à ranger dans la catégorie « bénin ».

L’enseignement

Deux questions à poser à votre équipe d’exploitation cette semaine. La première porte sur vos propres constructions automatiques : qu’est-ce que votre chaîne d’intégration évalue à partir d’un dépôt soumis par un tiers, et que peut-elle atteindre sur le réseau une fois lancée. La seconde porte sur le budget que vous donnez à vos agents : un agent contraint en temps choisit le chemin qui rentre dans l’enveloppe, et vous ne saurez pas lequel tant que vous ne journaliserez pas ses appels sortants.

Sources et références

• rubyhack.ai : Spencer Kitts, Thomas Larsen, Sydney Von Arx, rapport forensique sur la campagne GemStuffer (publié les 11 et 12 septembre 2026 ; chronologie, chiffres d’attribution, paquets qui se désarment après exécution, analyse de la faille de cache).
• Reuters : OpenAI agents attacked software service RubyGems before Hugging Face incident (11 septembre 2026 ; déclaration complète d’OpenAI, billet de RubyGems, prudence des chercheurs sur le mobile et le succès de la campagne).
• The Hacker News : OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers (détail du vecteur .yardopts, CVSS, correctifs successifs du registre).
• Simon Willison : lecture du rapport et signalement initial de Maciej Mensfeld (équipe sécurité RubyGems) le 12 mai 2026.
• The Decoder : hypothèse du budget de temps par tâche et disproportion entre le coût de l’attaque et la valeur de la cible.
• TECHi : position de Ruby Central (campagne coordonnée de publication de spam, constat non révisé) et déclaration de la porte-parole d’OpenAI au Wall Street Journal.