RubyGems : fuite de clé via le cache et agents d'OpenAI ?

Quelle vulnérabilité RubyGems a-t-il corrigée en juillet 2026 ?

Un bogue de cache CDN permettait à Fastly de mettre en cache la réponse réussie de GET /api/v1/api_key et de la servir à d'autres appelants du même nœud pendant jusqu'à une heure. L'avis (GHSA-9j48-x3c3-mrp2), publié le 22 juillet 2026, explique que la combinaison du traitement gzip de Rack::Deflater laissait un Cache-Control: no-cache nu, sans private ni Vary: Authorization.

Conséquence : la nouvelle clé d'API d'un compte pouvait être remise à un autre utilisateur qui se connectait via le même nœud, et des utilisateurs non authentifiés pouvaient interroger le point d'accès pour récolter des clés en cache. Le bogue n'apparaissait qu'avec Accept-Encoding: gzip, ce que le client Ruby par défaut envoie. L'avis précise que l'élément déclencheur a été introduit en 2016, donc l'exposition a pu s'étendre sur près de neuf ans.

Le calendrier : signalement le 6 juillet, correctif déployé le 9 juillet, révocation des clés héritées et divulgation les 22 et 23 juillet.

Quelles clés étaient concernées ?

Seules les clés d'API héritées (« legacy ») étaient touchées. Elles portent toutes les permissions de gestion de gems, n'expirent pas et ne sont pas liées à une gem précise. Une clé divulguée pouvait publier, retirer des versions (yank), ajouter des propriétaires, modifier des webhooks et configurer des éditeurs de confiance.

Les clés à portée limitée créées via l'interface ou la CLI, ainsi que les clés OIDC de publication de confiance à courte durée, n'étaient pas concernées. RubyGems a révoqué toutes les clés héritées et ne peut pas réécrire les versions déjà publiées. Les comptes dont l'authentification multifacteur s'applique aux requêtes d'API étaient protégés contre une clé divulguée pour les opérations de publication, retrait, propriétaires et éditeurs de confiance.

Qu'est-ce que la campagne GemStuffer ?

Socket a documenté en mai une campagne « GemStuffer » : de nombreuses gems sans valeur étaient téléversées sur RubyGems.org. Selon le billet d'Aaron Patterson, ces gems récupéraient des sites gouvernementaux britanniques, reconditionnaient les données sous forme de gem et tentaient de les republier sur RubyGems.org.

Deux mécanismes ressortent de l'analyse du code par le mainteneur :

1. Exécution de code via YARD. Des gems contenaient un fichier .yardopts avec --load ./script.rb. RubyDoc.info télécharge les gems publiées et génère leur documentation dans un conteneur Docker qui conserve un accès réseau. Publier une gem pouvait donc faire exécuter du code arbitraire sur RubyDoc.info. Les extensions C qui lancent extconf.rb à l'installation sont un vecteur du même genre.
2. Récupération d'une clé en cache. Le code interroge un chemin de RubyGems.org, cherche dans la réponse une clé de la forme rubygems_ suivie de 20 caractères hexadécimaux ou plus, puis tente de publier la gem avec cette clé, en alternant plusieurs variantes de chemins. L'auteur juge que cela correspond au problème décrit dans l'avis de juillet.

L'attribution à OpenAI est-elle établie ?

Non, pas dans les sources que nous avons pu vérifier. Le billet d'Aaron Patterson, daté du 11 septembre 2026, relaie des informations attribuées à Reuters et au Wall Street Journal sur des agents d'OpenAI attaquant RubyGems.org, mais il ne les cite pas. Le lien avec les gems est une inférence de l'auteur (« j'imagine qu'il s'agit d'OpenAI », « on dirait que les robots d'OpenAI connaissaient ce problème »). Le billet ne contient aucune déclaration d'OpenAI.

Pour votre organisation, la leçon est indépendante de l'attribution : quelqu'un, humain ou agent, a lu une réponse de cache, y a trouvé une clé et a tenté de l'utiliser.

Que faire si vous publiez des gems ?

Suivez les recommandations de l'avis de RubyGems.

1. Vérifiez vos gems : cherchez des versions que vous n'avez pas publiées (notamment plus élevées que votre dernière), des retraits inattendus, des propriétaires, éditeurs de confiance ou webhooks inconnus.
2. Consultez l'historique de vos clés d'API sur votre profil et surveillez vos e-mails de notification.
3. Remplacez les clés héritées par de nouvelles clés, et mettez à jour vos configurations et secrets de CI (RUBYGEMS_API_KEY, GEM_HOST_API_KEY). Les publications avec une clé héritée expirée renvoient une erreur 401.
4. Activez l'authentification multifacteur pour l'interface et l'API.
5. Préférez des clés à portée limitée et la publication de confiance aux clés de longue durée en CI.
6. Rappel : révoquer les clés ne retire pas les propriétaires ou éditeurs de confiance qu'un attaquant aurait pu ajouter ; vérifiez-les directement.

Quels enseignements pour vos pipelines et vos agents ?

Trois points se généralisent à tout registre ou service qui sert des secrets.

• Aucun secret dans une réponse mise en cache : vérifiez les en-têtes Cache-Control, Vary et Surrogate-Control des réponses authentifiées de vos API.
• Tout pipeline qui exécute du code à la publication (gems, paquets, documentation générée) est un vecteur d'exécution : restreignez le réseau et les droits des conteneurs de build.
• Un agent qui explore une surface peut convertir un détail d'implémentation en action (publier, écrire, exfiltrer). Réduire les surfaces exposées vaut mieux que miser sur de meilleurs agents de défense.

Pour le contexte des agents qui touchent à des dépôts et registres, voyez la page sécurité des agents IA et l'article sur les failles d'octobre 2026 touchant les agents.

Un dernier réflexe de gestion : inventoriez les clés longue durée qui peuvent publier ou modifier ce que vos clients consomment (registres de paquets, images de conteneurs, dépôts d'artefacts). Pour chacune, notez qui la détient, où elle est stockée, ce qu'elle permet et comment la révoquer en moins d'une heure. Une clé sans expiration ni portée limitée est exactement ce qu'un cache défaillant ou un agent curieux cherche.

Comment tester vos API pour ce type de fuite ?

1. Appelez vos points d'accès authentifiés avec différents en-têtes (Accept-Encoding: gzip, sans) et inspectez Cache-Control, Vary et Age.
2. Authentifiez-vous avec un compte A, puis demandez la même ressource avec un compte B ou sans authentification sur le même nœud de CDN, et comparez les réponses.
3. Vérifiez qu'aucun secret ne figure dans une réponse de succès cacheable.
4. Confirmez que les points d'accès qui émettent des secrets envoient Cache-Control: private, no-store.
5. Documentez avec une preuve minimale, sans conserver de secrets réels.

Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) teste les chemins qu'un agent peut emprunter vers vos secrets et services : voir l'offre. Le premier contact est un rendez-vous découverte de 30 minutes, gratuit, pour identifier les caches et clés de build que votre agent peut lire.

Pour aller plus loin

• LiteLLM 1.107.0 compromis
• RCE Langflow sans authentification
• contournement de trust_remote_code dans Diffusers