L’équipe Rust a signalé jeudi une attaque visant un crate très populaire, arrayref. Elle a permis, pendant un peu plus d’une heure, de distribuer des composants vérolés vraisemblablement destinés à la récupération de mots de passe sur les machines des utilisateurs finaux. L’incident, rapidement contenu, s’inscrit dans une longue liste d’attaques visant la chaîne d’approvisionnement.

L’équipe en charge de la maintenance du langage Rust et de ses composants a alerté jeudi 20 août d’une attaque visant arrayref, un crate (l’unité de compilation de base, qui se présente soit sous forme de binaires, soit comme une bibliothèque) très courant.

Pour ce faire, les auteurs ont réussi à publier sur crates.io, le registre de paquets Rust, un composant baptisé proc-macro1. Il contenait un build script (code qui s’exécute à la compilation) ayant pour objet de déclencher le téléchargement d’une charge malveillante de type infostealer (vol de données).

Une charge calculée pour extraire des données

Pour favoriser la diffusion de leur attaque (dont le nom est une forme de typosquatting d’un autre crate légitime, proc-macro2), les attaquants ont réussi à modifier le crate arrayref pour que leur charge soit appelée lors de l’utilisation de ce dernier. Ils ont également piégé de la même façon d’autres composants courants (internment, append-only-vec).

D’après l’équipe Rust, la fenêtre de diffusion s’est heureusement révélée limitée, suite à une alerte rapidement formulée par les chercheurs de Nextron Systems. Elle estime ainsi que les composants vérolés sont restés en ligne entre 90 et 107 minutes : un laps de temps trop court pour permettre une propagation à grande échelle, mais tout de même suffisamment long pour que des développeurs aient pu être touchés.

« Nous vous recommandons de vérifier vos dépendances locales pour vous assurer que ces crates n’ont pas été téléchargées », déclare ainsi l’équipe Rust, qui invite à vérifier le contenu du dossier ~/.cargo/registry/cache pour y débusquer les éventuelles versions vérolées.

Deux chercheurs de l’entreprise de cybersécurité Wiz (passée aux mains de Google en mars 2026) ont détaillé le contenu exact de la charge malveillante. Lancée donc dès la compilation, elle a vocation à reconstruire une URL de destination pour l’envoi de données volées, désactiver la validation d’un certificat TLS et ainsi autoriser le contrôle et commande à distance (C2).

Elle télécharge ensuite un composant spécifique à l’OS et à l’architecture de la machine et lance ce dernier, qui commence ensuite à extraire des informations, en s’intéressant notamment aux identifiants stockés au niveau du navigateur. Il s’installe par ailleurs de façon persistante, soit via le registre Windows, soit au moyen de LaunchAgent (macOS) ou systemd (Linux).

Le compte d’un mainteneur compromis

Les attaquants n’ont probablement pas choisi leur cible au hasard. Le crate arrayref compte en effet la bagatelle de 245 millions de téléchargements, et il est utilisé comme dépendance dans 400 autres crates populaires, utilisés notamment sur les chaînes de blocs Ethereum et Solana, associées à des cryptomonnaies bien connues.

La subtilité ici réside dans le fait que le crate arrayref ne comportait en tant que tel aucun code malveillant, notent les chercheurs de Step Security : c’est simplement son fichier de dépendances qui était modifié.

La version corrompue, arrayref@0.3.10, semble avoir été publiée depuis le compte d’un mainteneur Rust historique, et non des moindres puisqu’il s’agirait de l’auteur du crate initial, initialement publié il y a 15 ans. « Nous ne pensons pas que l’auteur d’arrayref agisse de manière malveillante, mais son ordinateur ou ses identifiants sont probablement compromis, et nous essayons de le contacter », indique l’équipe Rust.

Dans la foulée de la publication, les attaquants ont yanké (retiré) les versions 0.3.5 à 0.3.9 du crate arrayref pour que les développeurs soient enclins à lancer cargo update, la commande de mise à jour censée précisément les protéger lorsque leur environnement exploite une version obsolète (et donc potentiellement vulnérable) d’un composant.

L’attaque a donné lieu à la publication, vendredi, d’une CVE (2026-77651) qualifiée de critique avec un score de 9,8.

Pour Wiz, le mode opératoire et une adresse IP détectée par l’une des victimes de l’attaque rappellent directement de précédentes attaques sur la chaîne d’approvisionnement (supply chain) telles que celles menées ces derniers mois contre Trivy, Axios et npm.