Compiler ce crate a lancé le programme d'un attaquant

La première nouvelle dépendance en dix ans

Le 20 août 2026, un attaquant qui avait compromis un compte de mainteneur sur crates.io, le registre officiel des paquets Rust, a utilisé cet accès pour publier des versions piégées de trois crates très utilisés : arrayref, internment et append-only-vec. Arrayref à lui seul est présent dans plus de 35 pour cent de tous les environnements Rust et dans environ trois environnements sur quatre où Rust apparaît, ce qui en fait l'une des petites bibliothèques les plus omniprésentes de tout l'écosystème, bien que presque invisible.

La version malveillante arrayref 0.3.10 portait un détail qui aurait dû à lui seul être un signal d'alarme : c'était la toute première nouvelle dépendance qu'arrayref ait jamais ajoutée en dix ans d'histoire. Qu'un crate reste sans dépendance pendant une décennie en acquière soudain une est exactement le genre de changement qu'une revue attentive des dépendances devrait signaler, si tant est que quelqu'un la faisait vraiment.

Un script de build exécuté avant tout code

Chaque version piégée ajoutait une dépendance vers un nouveau crate appelé proc-macro1, lui aussi malveillant. Proc-macro1 contenait un script de build, un petit programme que Cargo, l'outil de build de Rust, exécute automatiquement lors de la compilation d'un projet, avant même que le code du projet lui-même ait fini d'être construit ou exécuté.

C'est précisément cette exécution automatique qui a rendu l'attaque si discrète : un développeur ou un pipeline CI n'avait pas besoin d'exécuter le binaire final, de cliquer sur quoi que ce soit ni d'importer une fonction suspecte pour être compromis. Il suffisait de lancer cargo build sur un projet dépendant du crate piégé pour déclencher le script de build et télécharger la charge utile de l'attaquant.

Retrait et coup de pouce : un procédé emprunté à npm

L'attaquant a également retiré les anciennes versions saines d'arrayref, de la 0.3.5 à la 0.3.9, du registre. Un retrait ne supprime pas totalement une version, mais il fait afficher à Cargo son avertissement habituel selon lequel un projet devrait envisager de passer à une version qui n'est pas retirée.

Avec chaque version saine marquée comme retirée, la seule version non retirée qu'il restait à Cargo à recommander était la malveillante 0.3.10, poussant les développeurs vers la version piégée par le biais des propres outils du registre. Des chercheurs en sécurité avaient déjà repéré ce même schéma de retrait et de coup de pouce dans de précédentes attaques de la chaîne d'approvisionnement npm, si bien que son apparition sur crates.io évoque le même scénario d'ingénierie sociale via les outils, et non une invention nouvelle.

Trois crates, trois courtes fenêtres

Les trois versions malveillantes ont été publiées en l'espace de 22 minutes dans la matinée du 20 août 2026, et toutes les trois ont été retirées en 90 à 107 minutes environ après leur mise en ligne, une fois que la Rust Security Response Team a verrouillé le compte compromis et retiré les paquets.

Une fenêtre de moins de deux heures paraît brève, mais crates.io n'a aucun délai intégré entre la publication d'une nouvelle version et le moment où chaque projet dépendant peut la récupérer automatiquement lors de sa prochaine build, si bien que même une fenêtre courte suffit pour qu'un script de build atteigne tout projet qui se reconstruit justement à ce moment-là.

Vol d'identifiants, un kill switch et un lien avec la Corée du Nord

Wiz Research a analysé la charge utile et trouvé une porte dérobée qui communique avec un serveur distant via HTTPS, énumère les identifiants enregistrés dans Chrome, Brave et Edge, installe une persistance multiplateforme et peut exécuter quatre commandes distantes distinctes, dont un kill switch et une commande pour exécuter des scripts arbitraires.

Wiz a également constaté que le point de connexion de la porte dérobée partage son infrastructure avec la campagne Mastra, que Microsoft a attribuée à Sapphire Sleet, un groupe lié à la Corée du Nord, et avec une attaque antérieure contre le paquet npm axios que Google Cloud Threat Intelligence et Mandiant ont séparément également rattachée à la Corée du Nord, ce qui suggère que le même type d'acteur ayant déjà compromis npm a désormais démontré la même capacité contre crates.io. La découverte est attribuée à Nextron Systems GmbH, une société allemande de sécurité ; la Rust Security Response Team a verrouillé le compte et retiré les trois versions, et aucune preuve confirmée d'exploitation réelle n'a été trouvée à ce jour.

Rust résout les bugs mémoire, pas la question de qui contrôle le compte

Le Cyber Resilience Act de l'UE et la NIS2 poussent depuis un moment les fabricants de produits critiques pour la sécurité et connectés vers des langages memory-safe, et Rust a été l'un des principaux bénéficiaires de cette poussée. Cet incident rappelle qu'une migration vers Rust pour des raisons de conformité résout un problème, les bugs de sécurité mémoire comme les dépassements de tampon, sans toucher à un autre, totalement distinct : qui contrôle le compte qui publie les dépendances d'un projet, et ce qu'un script de build est autorisé à exécuter avant même que le code du projet lui-même ait fini de compiler.

Les dirigeants qui ont ordonné une migration vers Rust pour des raisons de conformité devraient poser trois questions concrètes à leurs équipes d'ingénierie : les mises à jour de dépendances sont-elles revues avant fusion, le pipeline CI peut-il isoler ou restreindre ce qu'un script de build a le droit de faire, et quelqu'un remarquerait-il vraiment un retrait puis une republication le même jour sur un paquet auquel l'équipe fait confiance depuis des années. Il vaut la peine de noter que la découverte elle-même vient de Nextron Systems GmbH, une société allemande, ce qui dément toute idée que ce risque de chaîne d'approvisionnement ne concernerait que les autres.

À lire ensuite: Personne ne peut vérifier la puce de votre clé de sécurité  |  Votre budget de primes achète du déchet d'IA