Trois crates Rust compromises distribuent un malware lors de la compilation

Trois versions malveillantes retirées de crates.io

Le projet Rust a retiré de crates.io trois versions compromises de crates largement utilisés : arrayref 0.3.10, internment 0.8.7 et append-only-vec 0.1.9.

Ces versions ont été publiées le 20 août 2026 par le même compte propriétaire et sont restées disponibles entre 86 et 107 minutes :

• arrayref 0.3.10 : de 07:15:00Z à 08:41:40Z ;
• internment 0.8.7 : de 07:34:07Z à 09:04:11Z ;
• append-only-vec 0.1.9 : de 07:37:49Z à 09:25:24Z.

Le Rust Security Response Team a reçu le premier signalement à 07:15 UTC, après la découverte d’un crate malveillant nommé proc-macro1. Ce nom imite celui du crate légitime proc-macro2 : une technique de typosquatting destinée à passer inaperçue dans les manifestes de dépendances.

Sont également considérés comme compromis, quelle que soit leur version : proc-macro1, proc-macro-en, aovine, arone, aronenao et tinymember.

Aucun identifiant CVE n’a été attribué. Les avis RustSec ne font état d’aucune preuve d’exploitation réelle des versions malveillantes. L’incident ne figure pas non plus dans le catalogue KEV de la CISA.

L’attaque se déclenchait lors d’une compilation Cargo classique

L’attaque ne nécessitait pas l’utilisation d’une fonction particulière des crates compromis. Il suffisait d’exécuter cargo build, cargo check ou cargo test sur un projet résolvant la dépendance altérée.

Le manifeste des versions concernées contenait une ligne supplémentaire destinée à introduire proc-macro1. Le crate contrefait incluait le code source authentique de proc-macro2, afin de conserver un comportement apparemment normal. L’élément malveillant était un script de build exécuté automatiquement pendant la compilation.

Le script reconstituait, à partir de fragments encodés en Base64, l’adresse du serveur de commande et contrôle ainsi que celle utilisée pour télécharger le payload. Il installait également un validateur TLS personnalisé dont les trois fonctions de validation renvoyaient toujours un résultat positif. En pratique, la vérification des certificats était désactivée.

Le code sélectionnait ensuite l’un de quatre payloads selon le système d’exploitation et l’architecture du processeur. Sous Unix et macOS, le fichier était écrit dans /tmp/rust-setup, rendu exécutable puis lancé en arrière-plan, l’adresse C2 étant transmise comme premier argument.

Sous Windows, deux fichiers étaient créés dans le répertoire temporaire de l’utilisateur :

• %TEMP%\rust-setup.ps1 ;
• %TEMP%\rust-setup-launch.vbs.

Le second était exécuté via wscript.exe en mode masqué. Le processus enfant était ensuite séparé du job object de Cargo, empêchant la compilation d’attendre sa terminaison.

Il en résultait une chaîne d’attaque intégrée à la phase de build, avant même l’exécution de l’application. Il s’agit d’une différence majeure par rapport à un malware activé uniquement par le comportement runtime du programme.

Le retrait des versions précédentes a facilité la diffusion

La publication d’arrayref 0.3.10 s’est accompagnée, dans la même minute, du retrait des versions légitimes 0.3.5 à 0.3.9. La version malveillante devenait ainsi la seule disponible dans la série compatible.

Cargo utilise des intervalles caret pour de nombreuses dépendances. Une contrainte telle que arrayref ^0.3.6 accepte donc toutes les versions compatibles de la série 0.3.x, y compris 0.3.10. Le chercheur GitHub jhobern a indiqué avoir découvert l’attaque précisément par ce mécanisme.

La portée potentielle d’arrayref est importante. Une vérification via l’API de crates.io, réalisée le 21 août 2026, a recensé :

• 245 385 500 téléchargements au total ;
• 53 905 601 téléchargements au cours des 90 jours se terminant le 20 août ;
• 403 crates distincts le déclarant comme dépendance.

Parmi les chaînes de dépendances figure winit, qui requiert sctk-adwaita ^0.10.1 ; ce dernier dépend de tiny-skia ^0.11, qui requiert à son tour arrayref ^0.3.6.

blake3 dépendait également d’arrayref jusqu’à la version 1.8.6, mais pas de la 1.8.7, publiée à 09:09 UTC. Les projets blake2b_simd et blake2s_simd ont supprimé cette dépendance dans des versions publiées respectivement à 09:25 et 09:26 UTC.

La méthode utilisée pour compromettre le compte reste inconnue. Le propriétaire légitime d’arrayref est l’utilisateur crates.io 2402, David Roundy, enregistré en octobre 2009. L’équipe Rust estime probable une compromission de l’ordinateur ou des identifiants, plutôt qu’une action volontaire de l’auteur.

Le payload installait une persistance et dérobait des données de navigateurs

Selon l’analyse de Wiz, l’étape suivante communiquait via des requêtes HTTPS POST vers le chemin /49890878. Le malware pouvait installer des mécanismes de persistance propres à chaque système d’exploitation :

• une clé Registry Run sous Windows ;
• un LaunchAgent sous macOS ;
• un service systemd utilisateur sous Linux.

Le composant prenait en charge quatre catégories de commandes : terminaison, modification du serveur C2, installation de la persistance, ainsi que téléchargement et exécution de scripts supplémentaires.

Wiz a également observé le vol d’identifiants dans les bases de données SQLite de Chrome, Brave et Edge. L’analyse menée par Nextron sur le payload Windows n’a toutefois détecté que la lecture des champs origin_url et username_value, sans extraction directe de password_value.

Les payloads Linux et macOS n’étaient disponibles que sous forme de hash et n’ont pas pu être analysés. Il n’est donc pas possible d’étendre automatiquement aux deux systèmes d’exploitation les conclusions tirées de l’échantillon Windows.

L’attribution reste ouverte. Wiz a signalé des recoupements d’infrastructure avec de précédentes campagnes nord-coréennes visant la supply chain, notamment les compromissions de Mastra npm et d’axios. Microsoft a associé l’opération Mastra à Sapphire Sleet, tandis que GTIG a attribué l’incident axios à MIDNIGHT NEPTUNE, précédemment désigné sous le nom UNC1069.

Aucun fournisseur n’a toutefois attribué cette campagne sur crates.io à un groupe spécifique.

Ce que les développeurs doivent vérifier

Le Rust Security Response Team a supprimé les versions malveillantes et révoqué leur précédent statut yanked afin de gérer l’incident. Pour arrayref, il est recommandé de rester sur la version 0.3.9 ou antérieure. Aucune version corrigée des trois versions compromises n’existe.

Les développeurs devraient :

1. vérifier ~/.cargo/registry/cache à la recherche des paquets supprimés ;
2. réexaminer les projets compilés avec cargo build, cargo check ou cargo test ;
3. rechercher les connexions vers les indicateurs connus ;
4. vérifier la présence des fichiers temporaires et des mécanismes de persistance ;
5. faire tourner les identifiants éventuellement utilisés sur les systèmes concernés.

Les indicateurs réseau comprennent :

• 23.254.165.112:9089, serveur de payload ;
• 23.254.165.112:443, infrastructure C2 ;
• hwsrv-798836.hostwindsdns.com.

Les noms de fichiers à rechercher sont /tmp/rust-setup, %TEMP%\rust-setup.ps1 et %TEMP%\rust-setup-launch.vbs. Les binaires identifiés comprennent rust-crate_0.1.0, _0.2.0, _0.3.0 et _0.4.0.

Les métadonnées associées aux comptes dtolney, identifié comme usurpateur, et droundy, associé au propriétaire légitime, doivent également être examinées. L’adresse [email protected] a aussi été signalée.

Le cas est documenté, pour arrayref, par l’avis RUSTSEC-2026-0260. Cargo ne dispose toujours pas d’un délai d’attente par défaut pour les dépendances nouvellement publiées : une proposition visant à stabiliser global-min-publish-age était encore ouverte le 21 août 2026.

Cet incident met en évidence le risque des dépendances mises à jour automatiquement et, surtout, des scripts exécutés lors de la compilation. Dans un cas précédent, en septembre 2025, deux crates malveillants n’activaient leur code qu’au runtime. Ici, le point d’entrée était au contraire le processus de build, souvent considéré comme une phase plus fiable de la chaîne logicielle.