Une attaque sur la chaîne d'approvisionnement Rust glisse un malware de build dans arrayref

Des attaquants ont publié le 20 août 2026 des versions malveillantes de trois crates Rust très utilisées - arrayref 0.3.10, internment 0.8.7 et append-only-vec 0.1.9 - sur crates.io, et quiconque a compilé un projet résolvant l'une d'elles a exécuté un malware sur sa machine. La charge s'exécutait pendant le cargo build lui-même : un développeur ou un runner CI n'avait jamais besoin d'appeler le code empoisonné pour être compromis.

La fenêtre d'exposition fut courte, pas le rayon d'impact. Selon The Hacker News, arrayref cumule 245 385 500 téléchargements, dont 53 905 601 dans les 90 jours précédant l'attaque, et 403 crates le listent comme dépendance directe. La société de sécurité Wiz indique qu'arrayref apparaît dans plus de 35% de tous les environnements qu'elle observe, et dans les trois quarts des environnements où Rust est présent.

Comment l'attaque a fonctionné

La Rust Security Response Team dit avoir reçu un signalement le 20 août à 7h15 UTC et vérifié que la nouvelle version d'arrayref « contenait un script de build qui téléchargeait une charge malveillante ». Les versions malveillantes n'ont pas touché au code d'arrayref lui-même. Elles ont ajouté une nouvelle dépendance nommée proc-macro1 - un typosquat de l'écosystème légitime proc-macro - dont le script de build télécharge et exécute un binaire distant à la compilation.

L'analyse de StepSecurity résume le mécanisme sans détour : « Il suffisait de compiler n'importe quel projet dont le lockfile résolvait arrayref 0.3.10 pour déclencher la charge. Le code de la crate n'a jamais besoin d'être appelé. » La même analyse a constaté que l'attaquant a retiré (yank) toutes les versions saines 0.3.x d'arrayref en une rafale scriptée, « transformant en mécanisme de livraison l'avertissement 'yanked version' de Cargo lui-même » - les développeurs réagissant à l'avertissement se mettaient à jour droit vers la version malveillante.

Selon Wiz, la porte dérobée téléchargée reconstruisait ses URL de commande et contrôle à partir de fragments Base64, désactivait la validation des certificats TLS et livrait des charges spécifiques à chaque plateforme avec persistance sous Windows, macOS et Linux, plus l'énumération d'identifiants depuis les profils de navigateurs. Outre proc-macro1, la Rust Security Response Team a identifié cinq autres crates contrôlées par l'attaquant : proc-macro-en, aovine, arone, aronenao et tinymember.

crates.io a retiré rapidement les versions malveillantes : arrayref 0.3.10 est restée en ligne 86 minutes, internment 0.8.7 90 minutes et append-only-vec 0.1.9 107 minutes, selon les horodatages rapportés par The Hacker News. StepSecurity observe que « l'opération entière, de la création du personnage à la suppression du registre, tient dans une seule matinée de travail ».

Qui est derrière

C'est le compte du mainteneur qui a été compromis, pas le mainteneur. « Nous ne pensons pas que l'auteur d'arrayref agisse avec malveillance ; son ordinateur ou ses identifiants sont probablement compromis », a déclaré la Rust Security Response Team dans sa divulgation.

Wiz rapporte que l'infrastructure de la campagne recoupe largement de récentes opérations nord-coréennes contre les chaînes d'approvisionnement : elle partage la même plage d'adresses Hostwinds 23.254.164.0/23 que la campagne npm Mastra attribuée à Sapphire Sleet, groupe lié à la RPDC, et son trafic de commande et contrôle visait une IP figurant dans l'analyse par Google Cloud Threat Intelligence des attaques npm contre axios, elles aussi attribuées à la Corée du Nord. Le mode opératoire déjà familier sur npm vient d'atteindre crates.io.

Ce que cela change pour les développeurs

Si l'une de vos machines ou l'un de vos runners CI a compilé un projet Rust dans la matinée du 20 août (UTC), vérifiez si le lockfile a résolu arrayref 0.3.10, internment 0.8.7 ou append-only-vec 0.1.9, et inspectez votre cache de registre local - l'avis de la Rust Security Response Team demande de vérifier la présence des noms de crates malveillantes listés ci-dessus dans les dépendances en cache. Traitez une machine qui a compilé l'une d'elles comme compromise, pas simplement exposée : selon Wiz, la charge installe une persistance et énumère les identifiants des navigateurs, donc faites tourner les secrets que cette machine pouvait atteindre.

La leçon structurelle : les scripts de build sont une surface d'exécution de code à distance, et les lockfiles en sont le contrôle. Un Cargo.lock commité fige des versions exactes ; pendant la fenêtre de 86 minutes, le chemin vulnérable était un cargo install frais ou un job CI sans verrouillage. Cette attaque a aussi transformé une fonction de sécurité en appât - avec l'astuce du yank, « une version retirée signifie mettre à jour tout de suite » n'est plus un réflexe sûr. Vérifiez vers quoi vous mettez à jour, et traitez une dépendance toute neuve apparaissant dans le diff d'une crate stable de longue date comme un signal d'arrêt immédiat.