veilletech.frCe qui se passe
Le 20 août 2026, la version 0.3.10 du paquet Rust arrayref ajoute la
première dépendance de son histoire — le paquet existe depuis une décennie. Cette
dépendance s'appelle proc-macro1 : un typosquat de proc-macro2, la
bibliothèque omniprésente de David Tolnay.
La chronologie tient en quelques heures. Un compte GitHub nommé dtolney est
créé, à une lettre du vrai dtolnay. Le compte crates.io correspondant suit. Une
première version de proc-macro1 est publiée : une copie conforme et inoffensive
de l'original, pure mise en scène. Puis vient la version qui ajoute des
dépendances de compilation qu'aucune bibliothèque de macros n'a de raison
d'utiliser.
Quatre minutes plus tard, arrayref 0.3.10 sort du compte de son propriétaire
légitime, mainteneur en règle depuis 2009 et présumé compromis. Dans la même
minute, les cinq versions précédentes sont retirées en rafale, à quelques
secondes d'intervalle : l'avertissement « version retirée » de Cargo pousse alors
les utilisateurs à monter — droit dans le piège.
L'exposition aura duré environ 86 minutes avant que crates.io ne retire les deux paquets.
Pourquoi ça compte
Le mécanisme est ce qui rend cette attaque redoutable. Le code malveillant vit
dans build.rs, le script de compilation. Compiler suffit à l'exécuter —
aucune fonction du paquet n'a besoin d'être appelée. Pendant ce temps, la
bibliothèque elle-même reste l'authentique proc-macro2 : les compilations
réussissent, et rien n'apparaît dans la sortie.
Le script reconstruit son infrastructure depuis des fragments encodés, récupère un binaire de seconde étape en TLS avec la validation de certificat explicitement désactivée, le dépose dans un répertoire temporaire et le lance détaché — en s'échappant du groupe de processus de Cargo pour que la compilation se termine sans attendre.
La portée est le second problème. arrayref cumule environ 245 millions de
téléchargements. La chaîne remonte jusqu'aux applications graphiques Rust via
winit, et l'analyse des dépendances inverses ajoute blake3, les variantes de
blake2, ainsi que des paquets de l'écosystème Ethereum et Solana.
Toute machine — poste de développeur ou agent d'intégration continue — ayant
résolu arrayref ^0.3 à neuf pendant la fenêtre a exécuté la charge avec les
privilèges de son utilisateur.
Ce qu'il faut faire
Vérifier les fichiers de verrouillage. Cherchez arrayref dans votre
Cargo.lock : la version 0.3.10, ou toute entrée nommée proc-macro1,
signifie que la charge s'est exécutée sur cette machine.
Chercher les traces. Un fichier rust-setup en zone temporaire, et tout
trafic sortant vers l'adresse IP documentée par StepSecurity.
En cas de doute, traiter la machine comme compromise. Rotation de tous les identifiants, jetons et clés qu'elle pouvait atteindre — secrets d'intégration continue et clés de signature compris — puis reconstruction depuis des sources saines de tout artefact produit après l'exposition.
Si vous êtes indemne, épinglez la dernière version saine. Et surtout, ne résolvez jamais un avertissement de version retirée par une montée aveugle : c'est exactement le réflexe que l'attaquant a exploité.
À retenir
Une attaque de chaîne d'approvisionnement n'a pas besoin que son code soit
appelé. Ici, build.rs s'exécute à la compilation, et la mise en scène — compte
imitant un mainteneur connu, version de rodage inoffensive, retrait en rafale des
versions saines — a transformé un garde-fou de Cargo en levier d'attaque.
Source : StepSecurity