Une gemme Ruby malveillante lançait un ver voleur d’identifiants dès l’installation

Socket, une équipe de recherche sur les menaces, a dit qu’installer la version 1.0.1 de la gemme Ruby strutil-core suffisait à lancer un ver voleur d’identifiants. Le paquet a été retiré de RubyGems environ cinq heures après la parution de la version malveillante. Socket n’a confirmé aucune victime.

Ce que Socket a trouvé

Dans un rapport publié le 6 novembre 2026 (en anglais), Kush Pandya de Socket décrit la séquence suivante :

• Un compte RubyGems nommé jamnajiea a publié une version propre strutil-core 1.0.0 le 1er novembre, puis la version 1.0.1 moins de deux heures plus tard.
• Le scanner de Socket a signalé le fichier malveillant 70 secondes après l’apparition de la 1.0.1. RubyGems a ensuite retiré les deux versions, environ cinq heures après la parution malveillante, selon une analyse bac à sable que Socket cite de Bitbison.
• La gemme était un nouveau paquet, pas un projet existant détourné. Socket n’a trouvé aucun projet public qui en dépendait, et n’a pas confirmé que le ver a infecté d’autres paquets à partir de cette gemme.
• Installer la gemme, ou exécuter bundle install contre un fichier de verrouillage qui se résolvait à la 1.0.1, suffisait. Une application n’avait pas à en faire un require.

L’installateur utilisait un crochet d’extension native que RubyGems exécute pendant gem install. Au lieu de compiler quelque chose d’utile, ce crochet téléchargeait une copie de l’environnement d’exécution JavaScript Bun et lançait un gros script groupé. Socket dit que la charge est une version plus récente du ver testmetest, lui-même issu de la famille Miasma née de la trousse Shai-Hulud rendue publique. Un code partagé ne prouve pas à lui seul que la même personne est derrière chaque version, note le rapport.

Ce que le script est écrit pour faire, d’après l’analyse statique de Socket et une exécution bac à sable de l’installateur, comprend :

• Recueillir des identifiants infonuagiques, d’intégration continue, de registres de paquets, SSH, d’outils d’IA et de portefeuilles, puis les envoyer à un serveur contrôlé par l’attaquant, avec GitHub et GitLab comme solutions de repli.
• Du code capable de republier des paquets empoisonnés vers RubyGems, npm et PyPI s’il obtient les bonnes clés d’API, plus d’autres routines de propagation. Socket a confirmé que ces routines sont présentes. Il n’a pas confirmé que cette gemme a réussi à publier quoi que ce soit en aval.
• Installer une persistance qui peut télécharger et exécuter d’autres scripts, et écrire de la configuration dans des outils de programmation par IA et des dépôts locaux, de sorte qu’ouvrir un projet peut relancer la charge.
• Une suite particulièrement dangereuse : si le ver a obtenu un jeton GitHub, il peut installer un surveillant qui supprime le dossier personnel de l’utilisateur lorsque ce jeton commence à être refusé. Révoquer le jeton, ce qui est d’habitude la première réaction, est ce qui déclenche la suppression.

Socket a aussi documenté un paquet PyPI lié, pystr-codec, publié le 31 octobre, qui utilisait le même serveur de collecte.

Ce que ça signifie pour vous

Si vous n’avez jamais installé strutil-core 1.0.1, il n’y a rien à nettoyer pour ce paquet précis. Les compteurs de téléchargements ne sont pas des décomptes de victimes, et Socket ne sait pas combien de systèmes ont installé la 1.0.1 pendant la courte fenêtre où elle était publique.

Si vous l’avez installée, désinstaller la gemme ne suffit pas. La charge est écrite pour persister hors du dossier de la gemme et pour conserver des identifiants de longue durée. Traitez cet ordinateur, et chaque secret qu’il pouvait atteindre, comme compromis.

Ce que vous pouvez faire

1. Cherchez strutil-core dans les fichiers Gemfile.lock, les caches d’intégration continue et les images de conteneurs. Si la 1.0.1 s’y trouve, isolez cet hôte avant de faire tourner quoi que ce soit.
2. Sur une machine Linux ou macOS infectée, arrêtez et retirez la persistance nommée par Socket (net-health-checker et pkg-runtime) avant de révoquer un jeton GitHub volé. Le rapport est explicite : révoquer le jeton d’abord peut amener le surveillant à supprimer le dossier personnel. Ensuite, faites tourner les identifiants depuis un appareil sain et reconstruisez l’hôte.
3. Faites tourner les identifiants RubyGems, npm, PyPI, GitHub, GitLab, infonuagiques, SSH et de fournisseurs d’IA qui étaient accessibles à toute machine ou exécuteur d’intégration continue touché.
4. Passez en revue les paquets que vous maintenez à la recherche de mises à jour inattendues, surtout une gemme qui a soudain gagné un script d’installation que vous n’avez pas ajouté, et retirez les crochets d’outils d’IA ou d’éditeur non reconnus que le rapport décrit si vous les trouvez.

Comment Frame peut aider

Il s’agit ici d’un paquet malveillant sur la machine d’un développeur, pas d’une liste publiée de courriels de clients. Les vérifications ci-dessus sont la partie utile. Si un avis ultérieur nomme des adresses de comptes ayant fuité, Frame peut aussi chercher vos adresses courriel vérifiées dans la base de données de fuites de Have I Been Pwned. Frame ne recueille ni ne conserve jamais les données divulguées elles-mêmes.

À lire aussi

• Une version malveillante de LiteLLM a volé des identifiants pendant environ deux heures : un autre voleur d’identifiants livré au moment de l’installation par un paquet d’outils pour modèles de langue.
• Des téléchargements du CLI d’OVHcloud ont été remplacés par un voleur de secrets : un outil de développement de confiance qui a livré autre chose que ce que les gens croyaient installer.

Sources

• Socket, Shai-Hulud Descendant Surfaces in Malicious Ruby Gem That Steals Credentials and Poisons AI Tools (en anglais), 6 novembre 2026