Une attaque chaîne d’approvisionnement Rust a été mise au jour sur crates.io. Des versions malveillantes de plusieurs crates populaires ont été publiées, puis retirées rapidement, après qu’un compte de mainteneur compromis a publié des releases contenant une dépendance typosquattée. Le point le plus préoccupant : le code malveillant n’attendait pas un appel explicite dans l’application. Il se déclenchait dès la compilation, via un script de build qui télécharge et exécute une charge distante.
Dans cet article, nous expliquons ce qui s’est passé, quelles versions ont été concernées, comment l’attaque fonctionnait, et quelles mesures pratiques les développeurs peuvent prendre pour limiter l’exposition.
Ce qui a été publié, puis supprimé sur crates.io
Les versions affectées sont les suivantes :
- arrayref 0.3.10
- internment 0.8.7
- append-only-vec 0.1.9
Elles ont été publiées depuis le même compte de propriétaire le 20 août 2026, puis retirées dans une fenêtre très courte, entre 86 et 107 minutes après leur mise en ligne.
Selon les informations communiquées, aucun correctif prêt-à-déployer n’a été annoncé, et aucune CVE n’a été attribuée. Les avis RustSec associés à ces crates n’auraient pas trouvé d’élément indiquant que des versions malveillantes aient réellement été utilisées.
Pourquoi l’attaque fonctionnait : déclenchement au moment du build
Le mécanisme central de l’attaque réside dans le fait que le code malveillant se trouvait dans un script de build d’une dépendance injectée. Concrètement, il suffisait que le projet résolve cette dépendance pendant la compilation.
Autrement dit, il n’était pas nécessaire que l’application appelle une API précise provenant des crates compromises. Le simple processus de compilation, dès qu’il rencontrait les artefacts et scripts concernés, pouvait suffire à exécuter le payload.
Le rôle de la dépendance typosquattée
Les releases compromises comportaient l’ajout d’une ligne dans leur manifeste de dépendance : elles déclaraient une dépendance sur une crate nommée proc-macro1, présentée comme une sorte de typosquat de proc-macro2 — une librairie très répandue.
Fait important : le code source de proc-macro1 était une copie légitime de proc-macro2. Les builds “semblaient donc normaux” côté compilation, puisque les fonctions attendues existaient. Mais le script de build associé à cette fausse dépendance ajoutait ensuite la partie dangereuse.
Pourquoi la fraude passait sous le radar
Un autre facteur a été mentionné : les versions précédentes de arrayref auraient été retirées (yanked) presque immédiatement après la publication de la version malveillante. Selon le rapport d’analyse, cela pouvait influencer l’attention et les avertissements de l’outil de dépendances, du fait que Cargo pouvait être amené à proposer une version sans indicateur de retrait, selon le scénario de résolution.
Comment le payload était installé et exécuté
Le script de build reconstituait l’infrastructure de commande et contrôle (C2) à partir de fragments encodés en base64 au moment du build. Ensuite, il mettait en place un vérificateur de certificat dont les méthodes valideraient systématiquement la connexion, ce qui revenait à désactiver la validation TLS.
Le payload sélectionnait ensuite une variante adaptée à l’environnement (système d’exploitation et architecture).
Sur Unix et macOS
Le mécanisme décris s’appuyait sur l’écriture d’un fichier binaire dans /tmp/rust-setup, puis sur sa mise en exécution. Le processus était alors lancé en mode détaché, avec l’adresse C2 fournie en premier argument.
Sur Windows
Sur Windows, l’approche passait par la création d’un script PowerShell dans le dossier temporaire, puis son lancement de façon discrète via un mécanisme impliquant wscript.exe et un script VBScript. Le processus enfant serait ensuite abandonné afin d’éviter que l’exécution ne soit bloquante pour le déroulement du build.
Qui a été touché, et quelle ampleur ?
Les données consultées montrent qu’arrayref comptait environ 245 millions de téléchargements au total, et plus de 53 millions sur les 90 jours précédant le 20 août 2026. De plus, des dizaines de crates sur crates.io dépendaient d’arrayref, ce qui augmente mécaniquement le nombre potentiel de projets pouvant se retrouver exposés au moment de la compilation.
Des vérifications supplémentaires auraient confirmé que, dans une chaîne de dépendances, certaines contraintes de version pouvaient permettre l’inclusion de la release malveillante, notamment parce que des plages de versions avec caret (format ^0.3.x) autorisent la version 0.3.10.
Persistance et exfiltration : ce que le malware faisait après coup
Les analyses mentionnent une implantation de deuxième étape capable de communiquer avec le C2 via HTTPS. La persistance est décrite sur plusieurs plateformes :
- Sur Windows : via une clé Registry Run
- Sur macOS : via un LaunchAgent
- Sur Linux : via un service utilisateur systemd
Le malware couvrait plusieurs commandes, allant de l’arrêt à la reconfiguration du C2, en passant par l’installation de persistance et le téléchargement de scripts supplémentaires.
Concernant la collecte d’informations, l’analyse a évoqué un vol de données liées aux navigateurs (notamment Chrome, Brave et Edge) en interrogeant des bases de données de connexion. L’analyse indique aussi que, pour l’artefact Windows étudié, les champs examinés ne comprendraient pas directement les mots de passe dans le cas observé, et que les artefacts Linux et macOS n’auraient pas été analysés de la même manière.
Indicateurs d’exposition (IoC) cités
Des indicateurs d’infection ont été partagés, notamment des adresses réseau, des chemins de fichiers temporaires et des noms d’exécutables observés.
- Réseau : 23.254.165.112:9089, 23.254.165.112:443, hwsrv-798836.hostwindsdns.com
- Fichiers : /tmp/rust-setup, %TEMP%\rust-setup.ps1, %TEMP%\rust-setup-launch.vbs
- Binaries : rust-crate_0.1.0, _0.2.0, _0.3.0, _0.4.0
Des informations relatives aux comptes ont également été listées, dont un utilisateur légitime présumé compromis du côté crates.io. D’autres éléments (comme des métadonnées d’auteur forgées) ont été mentionnés dans les indicateurs.
Que doivent faire les développeurs maintenant ?
Les recommandations pratiques indiquées aux développeurs visent à vérifier ce qui a pu être téléchargé et compilé localement.
- Rechercher dans le cache local Cargo : ~/.cargo/registry/cache pour repérer les fichiers des crates supprimées.
- Épingler arrayref sur une version 0.3.9 ou antérieure, en attendant une résolution considérée sûre.
À l’heure des informations disponibles, il n’y avait pas de version “patchée” formellement identifiée pour remplacer les releases retirées, ce qui rend le contrôle du cache et la stratégie d’épinglage d’autant plus importante.
Comparaison avec d’autres attaques de chaîne d’approvisionnement
Les analyses ont souligné des recoupements avec d’autres incidents de chaîne d’approvisionnement attribués ailleurs. Des organismes ont notamment mentionné que certains schémas d’infrastructure et de méthode rappellent des compromis récents associés à des groupes capables d’attaquer des écosystèmes tiers.
En revanche, pour l’incident crates.io, aucune attribution à un acteur nommé n’a été communiquée. Le point crucial reste la nature du vecteur : une compromission de compte et un ajout d’un mécanisme de build malveillant.
Vers des protections plus strictes contre les publications rapides
Enfin, l’incident met en évidence un problème de fenêtre temporelle : un dépôt malveillant peut être publié et retiré avant que les contrôles automatiques n’aient le temps d’agir. Dans ce contexte, il a été fait état de travaux en cours côté Cargo, incluant une idée de cooldown ou de délai minimal de publication globale afin de retarder l’usage de dépendances trop récentes.
Selon les informations mentionnées, une proposition de stabilisation visant ce comportement était encore en discussion au moment des faits.
Conclusion : agir vite, mais aussi vérifier son environnement
L’attaque chaîne d’approvisionnement Rust décrite ici montre comment une compromission de mainteneur peut mener à l’exécution de code malveillant dès la compilation, sans appel explicite côté application. Même si les versions incriminées ont été retirées en quelques dizaines de minutes, l’impact potentiel dépend fortement de la résolution des dépendances et des caches locaux.
En pratique, vérifiez votre cache Cargo, épinglez les versions sensibles lorsque c’est nécessaire et surveillez les recommandations de sécurité. C’est à ce niveau que vous réduisez le risque, même lorsque l’attaque est déjà “retirée” côté registry.
Source: https://thehackernews.com/2026/08/rust-supply-chain-attack-puts-build.html
