L'AUR est-il sûr ? Leçons de l'attaque de la chaîne d'approvisionnement 'Atomic Arch' (2026)

En juin 2026, la communauté Arch Linux a été frappée par l’un des plus grands incidents de chaîne d’approvisionnement de son histoire — une campagne que les chercheurs ont surnommée “Atomic Arch.” Des centaines de paquets dans l’Arch User Repository (AUR) ont été modifiés pour installer des logiciels malveillants. C’est le bon moment pour répondre à une question que chaque utilisateur d’Arch finit par se poser : l’AUR est-il sûr ?

La réponse honnête est : l’AUR est une ressource puissante et utile, mais elle n’a pas le même niveau de confiance que les dépôts officiels d’Arch, et la traiter comme si c’était le cas est exactement la manière dont des incidents comme celui-ci font du tort aux gens. Voici ce qui s’est passé, pourquoi c’était possible, et comment utiliser l’AUR sans se brûler les doigts.

Ce qui s’est passé lors de l’attaque “Atomic Arch”

Vers la mi-juin 2026, des chercheurs en sécurité et la communauté Arch ont identifié une campagne coordonnée affectant un grand nombre de paquets AUR. Les rapports sur le nombre exact variaient selon les sources — les chiffres allaient de plus de 400 à plus de 1 500 paquets — mais le mécanisme était cohérent :

• Les attaquants ont adopté des paquets AUR orphelins — des projets légitimes abandonnés par leurs mainteneurs d’origine — via le processus normal d’adoption de l’AUR.
• Ils ont ensuite modifié le PKGBUILD de chaque paquet (le script d’instructions de construction que les assistants AUR comme yay et paru exécutent lors de l’installation) pour intégrer discrètement des charges utiles malveillantes.
• La charge utile déployait un voleur d’informations basé sur Rust et, sur certains systèmes, un rootkit eBPF, conçu pour récolter des identifiants, des jetons d’accès et des clés SSH — avec les machines des développeurs et les environnements CI/CD en ligne de mire.

Un détail crucial limite les dégâts : les dépôts officiels d’Arch ([core], [extra], [multilib]) n’ont pas été affectés. Ces paquets passent par un processus plus strict, examiné par des mainteneurs. Les mainteneurs ont annulé les commits malveillants, banni les comptes incriminés et publié une liste des paquets affectés.

Pourquoi l’AUR est structurellement plus risqué

Ce n’était pas un événement exceptionnel — c’est l’AUR fonctionnant exactement comme prévu, utilisé contre ses utilisateurs. L’AUR est un dépôt communautaire de scripts de construction, pas de binaires vérifiés. Lorsque vous installez depuis l’AUR :

• Vous exécutez un PKGBUILD écrit par un inconnu, sans examen de sécurité obligatoire.
• Les assistants AUR exécutent ce script sur votre machine, donc un PKGBUILD malveillant peut exécuter du code arbitraire pendant la construction.
• Les paquets orphelins peuvent changer de mains. Un paquet auquel vous faisiez confiance depuis des années peut être adopté par un nouveau mainteneur anonyme du jour au lendemain.

Rien de tout cela ne rend l’AUR “mauvais” — cela en fait un modèle de confiance différent. Les dépôts officiels sont organisés ; l’AUR est soumis par les utilisateurs. L’erreur est de traiter yay -S quelquechose comme pacman -S quelquechose.

Comment vérifier un paquet AUR avant de l’installer

Quelques minutes d’habitude auraient arrêté la plupart des victimes de cette campagne. Avant d’installer quoi que ce soit depuis l’AUR :

• Lisez le PKGBUILD — à chaque fois. La plupart des assistants AUR proposent de l’afficher (yay le demande ; ou exécutez paru --print). Regardez les URL source= et les fonctions prepare/build/package. Soyez méfiant envers tout ce qui récupère des scripts supplémentaires, des paquets npm/pip, ou des fichiers depuis des domaines inattendus.
• Lisez aussi le fichier .install. Les hooks d’installation s’exécutent avec des privilèges élevés — c’est un endroit favori pour se cacher.
• Vérifiez le mainteneur et l’historique. Les paquets récemment adoptés ou orphelins, les nouveaux mainteneurs, ou un changement soudain de mainteneur sont exactement le drapeau rouge exploité par cette campagne.
• Vérifiez les votes et l’âge. Très peu de votes sur un paquet prétendant être un logiciel populaire, ou une mise à jour récente suspecte, méritent d’être examinés — mais rappelez-vous que la popularité n’est pas une preuve de sécurité.
• Préférez les dépôts officiels lorsque le paquet y existe. S’il est dans [core]/[extra], utilisez pacman, pas l’AUR.
• Ne construisez jamais en tant que root, et envisagez de construire dans un conteneur ou une VM propre pour tout ce dont vous n’êtes pas sûr.

Le principe est simple : sur l’AUR, vous êtes le processus de révision. Si vous ne lisez pas le script, ne l’exécutez pas.

Si vous avez peut-être installé un paquet compromis

Parce que cette campagne ciblait les identifiants, supposez une exposition et agissez rapidement si vous avez installé un paquet signalé :

• Changez tout ce que le logiciel malveillant pourrait atteindre : clés SSH, jetons API, identifiants cloud et CI/CD, et tout mot de passe stocké dans des fichiers en clair ou l’historique du shell.
• Examinez la liste des paquets affectés publiée par les mainteneurs et supprimez tout ce qui est signalé.
• Inspectez pour la persistance (services inattendus, hooks, modules du noyau) et, en cas de doute, réinstallez à partir de médias propres — le travail d’un rootkit est de survivre au nettoyage.

La conclusion

L’AUR est-il sûr ? Il est aussi sûr que l’attention que vous lui portez. L’attaque Atomic Arch n’a pas compromis les dépôts officiels d’Arch ni pacman — elle a exploité l’habitude humaine d’installer des paquets AUR sans les lire. Gardez l’AUR pour ce qu’il fait de mieux, appuyez-vous sur les dépôts officiels quand vous le pouvez, et lisez le PKGBUILD avant chaque installation. Cette simple habitude fait la différence entre un gestionnaire de paquets pratique et un canal d’exécution de code arbitraire.