Le 11 juin 2026, chercheurs et communauté Arch Linux ont révélé une attaque de la chaîne logicielle de grande ampleur contre l'Arch User Repository (AUR), baptisée Atomic Arch par Sonatype. Première vague : 408 paquets détournés. Le lendemain, une seconde vague portait le total à plus de 1 500 paquets compromis. Le mode opératoire est d'une simplicité gênante : adopter des paquets orphelins, piéger leur script de build, et exécuter du code malveillant à l'installation.
J'utilise Arch sur plusieurs machines, et comme beaucoup je tape yay -S sans
trop réfléchir à ce que je viens d'autoriser. Cette campagne m'a obligé à traiter
l'AUR pour ce qu'il est : un registre de dépendances, avec exactement les
mêmes risques que npm ou PyPI. Voici ce qui s'est passé, comment savoir si vous
êtes touché, et surtout ce que j'en tire côté défense, ancré dans le référentiel
SOCLE.
Ce que vous allez apprendre
- Comprendre pourquoi l'AUR est une surface d'attaque comme un autre registre
- Reconstituer le mécanisme d'Atomic Arch, de l'adoption de paquet au payload
- Vérifier si vos postes Arch, Manjaro ou EndeavourOS sont concernés
- Réagir : identifier, faire tourner les secrets, reconstruire si besoin
- Ancrer la leçon dans des exigences concrètes plutôt que des bonnes intentions
L'AUR, ce dépôt communautaire qu'on oublie de traiter comme une dépendance
L'AUR n'est pas un dépôt officiel d'Arch Linux. C'est un espace communautaire où n'importe qui publie des recettes de build, les PKGBUILD, que des assistants comme yay ou paru téléchargent et exécutent sur votre machine. Les dépôts officiels d'Arch n'ont pas été touchés par cette campagne, et c'est un point important : le problème n'est pas Arch, c'est la confiance implicite qu'on accorde au contenu communautaire.
Particularité de l'AUR qui a tout permis : quand un mainteneur abandonne un paquet, un autre utilisateur peut l'adopter et hériter de son nom et de sa réputation accumulée. Un paquet orphelin mais encore installé par des milliers de personnes devient donc un actif convoité.
Ce qui s'est passé : adopter l'orphelin, piéger le PKGBUILD
L'attaque suit trois temps, méthodiques :
- Adoption de paquets orphelins : les attaquants reprennent, via le mécanisme normal de l'AUR, des paquets abandonnés mais à base d'utilisateurs réelle.
- Injection dans le PKGBUILD : ils modifient le script de build pour y ajouter
des dépendances malveillantes, masquées en paquets npm anodins
(
atomic-lockfile,js-digest). - Exécution à l'installation : au prochain
yay/paru, le PKGBUILD piégé télécharge et lance la charge, avec les droits de l'utilisateur qui installe.
Il n'y a ni faille zero-day, ni signature contournée : juste l'exécution de code arbitraire que tout PKGBUILD autorise par conception, déclenchée par un paquet dont le nom inspirait confiance. C'est du typosquatting inversé : pas un faux nom, mais un vrai nom détourné.
Le payload : voleur Rust et rootkit eBPF
La charge est un voleur d'identifiants écrit en Rust. Sur un système standard, il récolte : cookies et jetons de session du navigateur, clés SSH, jetons GitHub et npm, identifiants cloud et clés d'accès Docker. De quoi rebondir bien au-delà du poste compromis, vers vos dépôts et vos infrastructures.
Le rayon d'explosion immédiat se limite aux systèmes Arch Linux, Manjaro, EndeavourOS et aux installations Arch sous WSL2 qui consomment l'AUR. Mais les secrets exfiltrés, eux, n'ont pas de frontière.
Êtes-vous concerné ?
Posez-vous trois questions :
- Utilisez-vous Arch, Manjaro ou EndeavourOS (y compris sous WSL2) ?
- Avez-vous installé ou mis à jour des paquets AUR depuis le début juin 2026 ?
- Ces paquets ont-ils été récemment adoptés par un nouveau mainteneur ?
Si oui aux deux premières, considérez-vous comme potentiellement exposé jusqu'à preuve du contraire. La communauté a publié des outils de détection (voir les sources) pour repérer les PKGBUILD piégés et les indicateurs connus.
Action immédiate
Supprimer le paquet ne suffit pas : si le voleur a tourné, les identifiants sont déjà partis. La priorité, c'est la rotation.
Ce que SOCLE en retient
C'est là que je relie l'incident à des exigences opposables plutôt qu'à des
voeux pieux. Dans SOCLE, Atomic Arch relève de l'étape
Registres & publication, via deux
vecteurs : le détournement de compte d'éditeur (V-REG-1) et la
publication avec des identifiants valides (V-REG-4). La
fiche d'incident SOCLE
détaille le tout.
Quatre exigences l'auraient rendu beaucoup plus difficile :
- SOCLE-REL-PUB-1 : compte de publication protégé par MFA résistante au phishing (WebAuthn/FIDO2). Un mainteneur protégé ainsi ne se fait pas détourner son compte aussi facilement.
- SOCLE-REL-GEN-6 : publication par trusted publishing (identité OIDC courte) plutôt que par jetons de longue durée, qui fuient et se rejouent.
- SOCLE-INT-GEN-7 : dépendances épinglées par empreinte (digest), jamais par nom mutable, pour qu'un paquet détourné ne se substitue pas silencieusement à celui attendu.
- SOCLE-DPL-GEN-4 : vérification de provenance à l'admission, contre une source et un builder attendus.
Aucune de ces exigences n'est exotique. Toutes existent déjà ailleurs ; SOCLE les rassemble et les rend vérifiables. C'est la différence entre « il faudrait sécuriser nos dépendances » et un contrôle qu'on peut auditer.
Pourquoi ça se répète
Atomic Arch n'invente rien. C'est le même pattern que les compromissions npm, PyPI ou GitHub Actions de ces derniers mois : un compte de mainteneur ou un nom de confiance est repris, puis sert de canal de distribution à grande échelle. La cible change (AUR cette fois), le mécanisme reste : confiance héritée + exécution automatique à l'installation + republication de masse.
Tant que la défense repose sur « je fais confiance au nom du paquet », l'attaque gagne. Le réflexe à ancrer, c'est de traiter chaque registre comme une surface hostile : identités de publication fortes, épinglage par empreinte, quarantaine avant adoption, et détection des republications anormales.
À retenir
- L'AUR est un registre de dépendances : mêmes risques que npm ou PyPI, à traiter pareil.
- Atomic Arch a détourné 400+ puis 1 500+ paquets via l'adoption de paquets orphelins et des PKGBUILD piégés.
- Le payload Rust vole les secrets ; en root, un rootkit eBPF rend le poste irrécupérable autrement que par reconstruction.
- Les dépôts officiels Arch ne sont pas touchés : le risque est la confiance dans le communautaire.
- Après coup, rotation des secrets d'abord, suppression du paquet ensuite.
- Les exigences SOCLE REL-PUB-1, REL-GEN-6, INT-GEN-7 et DPL-GEN-4 visent exactement ce vecteur.
- Le pattern (compte détourné, exécution auto, republication de masse) se répète : la parade est structurelle, pas ponctuelle.