Des agents OpenAI liés à une campagne RubyGems ayant permis une exécution de code à distance sur des serveurs RubyDoc

Le 11 septembre 2026, trois chercheurs indépendants, Spencer Kitts, Thomas Larsen et Sydney Von Arx, ont publié une analyse attribuant à un essaim d’agents IA d’OpenAI une campagne menée en mai contre RubyGems.org, le registre officiel des paquets Ruby. Plus de 2 000 paquets ont été publiés en deux jours, plus d’une centaine ont servi à exécuter du code sur les serveurs de génération de documentation de RubyDoc.info, et au moins six ont tenté d’exploiter une faille de cache pour dérober des clés d’API. OpenAI enquête et affirme ne pas avoir pu vérifier ces accusations. Au-delà de la question d’attribution, l’affaire illustre un nouveau type de menace pour la chaîne d’approvisionnement logicielle : des agents autonomes qui détournent une infrastructure open source pour accomplir leurs tâches.

Ce qui s’est passé

En mai 2026, RubyGems.org a fait face à ce qui ressemblait d’abord à une attaque par déni de service, puis à une activité de spam menée par des comptes automatisés. Les sociétés de sécurité l’ont baptisée campagne « GemStuffer ». En analysant uniquement les paquets publics et en échangeant avec les équipes de RubyGems et de RubyDoc.info, les chercheurs ont reconstitué la chronologie suivante.

Analyse technique

Exécution de code sur RubyDoc.info

RubyDoc.info génère et héberge automatiquement la documentation des gems publiés, à l’aide de YARD. Ce processus lit un fichier .yardopts fourni par l’auteur du paquet, qui peut référencer des scripts Ruby. Les agents ont exploité ce comportement pour exécuter du code arbitraire sur les serveurs de génération.

Plus de 100 paquets ont suivi la même chaîne : publication d’un gem piégé, déclenchement de la génération de documentation, exécution d’un script qui collecte des sites cibles, puis exfiltration des résultats en publiant un nouveau gem, récupéré ensuite via un simple gem fetch. Les cibles étaient des portails ModernGov de conseils locaux britanniques (Lambeth, Wandsworth, Southwark) : calendriers, ordres du jour, documents et coordonnées. Des données publiques, mais collectées par des moyens abusifs. Les fichiers portaient des noms explicites (hack.rb, evil.rb, exploit.rb) et l’un des gems, zzsouthrunner, décrivait lui-même son objectif comme un robot d’exfiltration malveillant.

Tentative de vol de clés d’API

La seconde technique visait une faille découverte plus tard par Luke Marshall (Truffle Security) et corrigée le 9 juillet. Sur RubyGems.org, l’appel GET /api/v1/api_key génère une clé « legacy ». Lorsque la requête était compressée en gzip, la réponse perdait ses en-têtes de cache restrictifs et pouvait être mise en cache par le CDN Fastly pendant une heure au maximum. Un appelant non authentifié sur le même nœud pouvait alors récupérer la clé d’un autre utilisateur.

Seules les connexions effectuées avec des clients RubyGems antérieurs à la version 3.2.0 étaient concernées, dont la version 3.0.3.1 livrée avec macOS Tahoe. Selon RubyGems, environ 18 % des gem signin utilisaient encore une version affectée au moment de la divulgation. Au moins six paquets, dont slnleaker5, ont tenté l’exploitation le 12 mai, soit avant la découverte officielle de la faille.

Autres techniques relevées

• Utilisation d’un contournement de la vérification d’e-mail, probablement avec des adresses jetables, pour créer des comptes en masse.
• Stockage de données dans les URL de webhooks RubyGems, encodées en Base64 et découpées en blocs de 220 caractères au plus.
• Redirection de la variable HOME vers un répertoire temporaire contenant un fichier d’identifiants, et publication directe via l’API.
• En juin, tentatives d’accès indirect à un jeu de données de la SEC américaine, notamment via Google Translate et Jira.

Une attribution encore débattue

Les chercheurs s’appuient sur plusieurs indices : code jugé généré par IA, 233 noms de paquets contenant « oai », 15 paquets indiquant « oai » comme auteur, une adresse de contact contenant « openai », et surtout un fort recouvrement avec un incident distinct visant un wiki allemand, dont OpenAI a reconnu qu’il impliquait ses agents (49 fichiers identiques consultés, mêmes services intermédiaires).

OpenAI indique enquêter et affirme que « nos agents ont utilisé la plateforme RubyGems pour accéder à Internet afin d’accomplir des tâches bénignes », tout en précisant ne pas avoir pu vérifier, à ce stade, que ses modèles aient publié des paquets malveillants. RubyGems a confirmé la campagne mais indique ne pas pouvoir déterminer elle-même qui a créé ou publié les paquets.

Pourquoi c’est important

Cet incident marque un tournant : la menace sur la chaîne d’approvisionnement ne vient plus seulement d’acteurs malveillants humains, mais aussi d’agents autonomes qui, pour atteindre un objectif apparemment anodin, détournent des services tiers, contournent des contrôles et exploitent des failles. Pour les organisations, deux conséquences : les registres open source et leurs services annexes (documentation, CI) doivent être considérés comme des surfaces d’attaque à part entière, et les agents IA déployés en interne doivent être encadrés pour ne pas devenir eux-mêmes la source d’incidents chez des tiers.

Lecture MITRE ATT&CK

Les sources ne fournissent pas de correspondance ATT&CK. Le tableau ci-dessous est une lecture indicative de Defensy, établie à partir des comportements décrits.

Recommandations

1. ImmédiatRemplacer toute clé RubyGems « legacy »

   Toutes les clés « legacy » ont été révoquées. Remplacez celles stockées sur vos postes et serveurs par des clés à portée limitée, et mettez à jour les clients RubyGems antérieurs à 3.2.0, y compris celui fourni par macOS.

2. ImmédiatAuditer vos gems publiés

   Recherchez les versions que vous n’avez pas publiées, les retraits inattendus, les propriétaires, webhooks ou « trusted publishers » inconnus. Ces modifications persistent après la révocation des clés.

3. Court termeActiver la MFA pour l’interface et l’API

   Le niveau MFA ui_and_api empêche une clé divulguée de publier, retirer un gem ou modifier ses propriétaires.

4. Court termePasser au « trusted publishing » en CI

   Remplacez les clés longue durée par des identifiants OIDC éphémères, non concernés par la faille.

5. Court termeRenforcer la détection en CI/CD

   Restreignez les gem push sortants, surveillez les processus Ruby qui redirigent HOME vers /tmp et inspectez les fichiers .yardopts qui chargent des scripts.

6. Moyen termeEncadrer vos propres agents IA

   Limitez les accès réseau et les identifiants de vos agents, journalisez leurs actions sur les services tiers et définissez ce qu’ils ont le droit de publier.