En bref

  • 20 août 2026 : trois crates Rust populaires (arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9) publiées depuis un compte compromis avec un infostealer intégré dans un build script
  • arrayref seule cumule 245 millions de téléchargements et est présente dans plus de 35 % des environnements Rust — le malware s'exécutait lors de cargo build, sans autre action
  • Attribution aux hackers nord-coréens par Wiz ; les crates ont été retirées en 86 à 107 minutes — auditez vos builds du 20 août entre 10h et 12h UTC

Les faits

Le 20 août 2026, trois crates du registre officiel Rust (crates.io) ont été publiées depuis le compte compromis d'Andrew Gallant, connu dans la communauté Rust sous le pseudonyme BurntSushi — mainteneur de ripgrep, un des outils de recherche en ligne de commande les plus populaires de l'écosystème, et l'une des figures les plus respectées de la communauté Rust. Les trois crates malveillantes sont arrayref 0.3.10, internment 0.8.7 et append-only-vec 0.1.9. Toutes trois ont été retirées de crates.io entre 86 et 107 minutes après leur publication, grâce à une réaction rapide de l'équipe de sécurité Rust. L'équipe Rust a précisé ne pas croire que Gallant ait agi de manière malveillante.

La technique d'attaque exploite une caractéristique propre à l'écosystème Rust. Les trois crates malveillantes introduisaient une dépendance typosquattée nommée proc-macro1 — à ne pas confondre avec la crate légitime proc-macro2. Ce package frauduleux contenait un build script, un mécanisme standard de Rust permettant d'exécuter du code arbitraire au moment de la compilation, qui téléchargeait et exécutait un binaire distant. Le vecteur d'attaque est donc la commande cargo build : le simple fait de compiler un projet Rust incluant l'une des trois crates compromises déclenchait l'exécution du payload malveillant sur la machine du développeur ou dans le pipeline CI/CD, sans aucune autre action requise.

L'amplitude potentielle de l'impact est exceptionnelle. arrayref seule cumule plus de 245 millions de téléchargements au total et est présente dans plus de 35 % des environnements Rust, selon les estimations de StepSecurity. Elle est particulièrement répandue dans des projets liés à la cryptographie, aux protocoles réseau et aux bibliothèques de bas niveau — des cibles de valeur maximale pour un acteur étatique cherchant à compromettre des outils de développement utilisés dans des applications de sécurité. internment et append-only-vec totalisent ensemble près de 19 millions de téléchargements supplémentaires.

L'attribution aux acteurs nord-coréens a été établie par les chercheurs de Wiz dans un rapport publié le 21 août 2026. L'analyse du payload révèle un "chevauchement significatif" avec les TTPs (Tactics, Techniques and Procedures) documentés dans des campagnes précédentes attribuées à la DPRK, notamment l'utilisation d'infrastructure de command and control similaire et des patterns de code identiques à des malwares nord-coréens connus. Wiz identifie plus précisément des similitudes avec les toolings utilisés dans l'Opération Dream Job — la campagne de Lazarus Group consistant à cibler des développeurs via de fausses offres d'emploi pour leur faire exécuter du code malveillant. SecurityWeek confirme cette attribution dans son analyse du même jour.

Le payload déployé est un infostealer : il collecte des credentials, des clés SSH, des tokens d'accès cloud (AWS, GCP, Azure), des wallets de cryptomonnaies et des fichiers de configuration sensibles présents sur la machine compromise. Dans un environnement CI/CD, ces mêmes données peuvent inclure des secrets d'infrastructure injectés comme variables d'environnement, des tokens d'accès aux registres de containers Docker, des clés de déploiement vers les environnements de production. La compromission d'un poste de développeur Rust dans une entreprise technologique peut donc très rapidement se transformer en compromission de la chaîne de build et des environnements de production downstream.

Le Blog officiel de Rust (blog.rust-lang.org) a publié une notice d'incident le 20 août 2026, confirmant la réactivité de l'équipe de sécurité dans le retrait des versions malveillantes. BleepingComputer décrit en détail le vecteur d'attaque et confirme que proc-macro1, la dépendance typosquattée utilisée comme vecteur, n'existait pas dans crates.io avant l'attaque — elle a été créée spécifiquement pour cet incident, ce qui suggère une opération préparée de longue date.

La fenêtre d'exposition de 86 à 107 minutes est courte en termes humains mais non négligeable dans un monde de CI/CD continu. Des pipelines automatisés qui se déclenchent à chaque commit, des builds nocturnes, des actions GitHub programmées — toutes ces automatisations peuvent avoir exécuté le payload malveillant pendant cette fenêtre sans qu'aucun humain ne l'ait observé en temps réel. La variabilité du timing entre les trois crates (86 min pour la première retirée, 107 min pour la dernière) complique par ailleurs l'analyse précise de la fenêtre d'exposition par organisation.

Cet incident illustre une tendance de fond inquiétante pour l'ensemble de l'écosystème du développement logiciel : après npm (compromission SolarWinds via update Orion, attaque sur le package keyv début août 2026), PyPI, et RubyGems, l'écosystème Rust n'est désormais plus épargné. La confiance implicite accordée aux mainteneurs de packages populaires — une confiance construite sur des années de contributions légitimes et reconnues — est précisément le vecteur qu'exploitent les acteurs sophistiqués. Compromettre un seul compte de mainteneur connu permet d'atteindre des millions de développeurs en quelques minutes.

Impact et exposition

Sont potentiellement concernés tous les développeurs, systèmes CI/CD et runners GitHub Actions ayant exécuté cargo build avec arrayref, internment ou append-only-vec entre approximativement 10h00 et 12h00 UTC le 20 août 2026. L'analyse de l'impact doit cibler en priorité les postes développeurs disposant d'accès à des systèmes de production, des secrets cloud ou des pipelines de déploiement. Les projets open source hébergés sur GitHub qui utilisent arrayref et dont les actions CI ont tourné pendant cette fenêtre méritent également une investigation, y compris pour vérifier l'absence de modification non autorisée du code source.

Recommandations

  • Vérifier vos logs CI/CD du 20 août 2026 entre 10h et 12h UTC — tout build Rust déclenché sur cette fenêtre doit faire l'objet d'une investigation
  • Inspecter votre Cargo.lock à la recherche de arrayref = "0.3.10" — si cette version apparaît, même plusieurs niveaux de dépendance en dessous de votre code, vous étiez exposés ; la commande cargo tree --package arrayref donne une vue précise de l'arbre de dépendances
  • Faire pivoter tous les secrets accessibles depuis les postes et systèmes CI/CD potentiellement exposés : tokens AWS/GCP/Azure, clés SSH, tokens GitHub/GitLab, mots de passe stockés dans les gestionnaires
  • Auditer les connexions réseau sortantes anormales dans vos logs système autour de 10h-12h UTC le 20 août — l'infostealer doit exfiltrer les données vers un serveur C2 identifiable
  • Mettre en place des alertes sur les build scripts effectuant des connexions réseau : un cargo build qui initie des connexions sortantes est un signal d'alerte fort à détecter systématiquement en CI/CD

Alerte critique

Si vous ou votre équipe avez exécuté un build Rust le 20 août 2026 entre 10h et 12h UTC avec des projets utilisant arrayref (même en dépendance transitive), considérez vos secrets comme potentiellement compromis. Rotation immédiate des credentials prioritaires et investigation forensique s'imposent. N'attendez pas la confirmation d'une exfiltration pour agir.

Nous n'utilisons pas directement arrayref — pouvons-nous être affectés via une dépendance transitive ?

Oui, c'est le risque principal. arrayref étant présente dans plus de 35 % des environnements Rust, une grande proportion de projets l'intègre via des dépendances transitives sans s'en rendre compte — elle est une dépendance de nombreuses bibliothèques cryptographiques et réseau largement utilisées. Pour vérifier : inspectez votre Cargo.lock à la recherche de "arrayref = 0.3.10" ; si cette version apparaît à n'importe quel niveau de l'arbre, vous étiez exposés pendant la fenêtre d'attaque. Utilisez cargo tree --package arrayref pour voir les chemins de dépendance précis.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit