En bref

  • 408 packages orphelins de l'Arch User Repository (AUR) compromis pour déployer un infostealer Linux couplé à un rootkit eBPF
  • Systèmes affectés : toutes les installations Arch Linux ayant utilisé yay, paru ou tout autre helper AUR depuis mi-mai 2026
  • Action requise : exécuter l'outil de détection communautaire, révoquer immédiatement tous les tokens et secrets présents sur les machines concernées

Les faits

Le 11 juin 2026, des membres de la communauté Arch Linux ont détecté des comportements anormaux dans les scripts de build de plusieurs packages de l'Arch User Repository. Ce qui s'est révélé être une campagne coordonnée de grande ampleur a rapidement été baptisée « Atomic Arch » par les analystes de Sonatype. En moins de 24 heures, les trackers communautaires avaient catalogué 408 packages compromis — Privacy Guides avançant même le chiffre de 1 500 dans son analyse du 12 juin 2026. L'AUR héberge plusieurs dizaines de milliers de packages community-maintained, faisant de cet incident l'un des plus importants de son histoire.

Le vecteur d'entrée est redoutablement élégant. Les attaquants ont ciblé des packages orphelins : des projets légitimes abandonnés par leurs mainteneurs d'origine. L'AUR dispose d'un processus standard d'adoption permettant à n'importe quel utilisateur enregistré de reprendre la maintenabilité d'un package orphelin. Les acteurs de la menace ont exploité ce mécanisme pour réclamer des dizaines de packages populaires, s'appropriant ainsi la confiance accumulée par ces projets auprès de la communauté. Une fois en possession des droits de mainteneur, ils ont procédé à des modifications chirurgicales des fichiers PKGBUILD — les scripts qui orchestrent la compilation et l'installation des packages sous Arch Linux.

La modification est minimaliste et difficile à détecter lors d'une relecture rapide : l'ajout d'une commande d'installation de deux packages npm frauduleux, atomic-lockfile et js-digest. Ces packages, publiés sur le registre npm, servent de dropper pour un payload ELF Linux nommé deps. Ce binaire est au cœur de la campagne : il s'agit d'un credential stealer complet avec un module optionnel de rootkit eBPF, activé uniquement lorsque le processus dispose des privilèges root sur le système cible.

Le champ des cibles du payload deps est particulièrement révélateur des intentions des attaquants. L'infostealer extrait les données de navigation (Chrome, Chromium, Firefox), les tokens stockés dans les applications Electron (Slack, Microsoft Teams, Discord), les identifiants GitHub et npm, les secrets HashiCorp Vault, les configurations Docker et Podman, les clés SSH et le matériel VPN, ainsi que les historiques shell bash et zsh. Cette liste n'est pas celle d'un attaquant cherchant à voler des cartes bancaires — c'est celle d'un acteur ciblant spécifiquement les développeurs pour pivoter vers des environnements de production et des dépôts de code source.

Le composant rootkit exploite eBPF (extended Berkeley Packet Filter), le framework d'exécution de programmes dans le noyau Linux introduit dans les versions 3.18+ et massivement enrichi depuis. Contrairement aux rootkits traditionnels basés sur des modules noyau (LKM) qui modifient directement le code du kernel, un programme eBPF est exécuté dans une sandbox noyau vérifiée par le verifier eBPF. Cette caractéristique lui confère une double propriété mortelle pour les défenseurs : une stabilité système comparable au code noyau natif, et une furtivité accrue face aux outils de sécurité conventionnels. Une fois chargé avec les privilèges suffisants, le rootkit eBPF peut intercepter des appels système, masquer des processus et des connexions réseau, et persister après la suppression du package malveillant initial.

La chaîne d'infection complète se déroule de manière transparente pour l'utilisateur final. Un développeur Arch Linux exécute yay -S nom-du-package ou paru -S nom-du-package. Le helper AUR télécharge et exécute le PKGBUILD modifié, qui installe silencieusement les packages npm malveillants en arrière-plan pendant la compilation du package légitime. Le payload deps s'exécute, exfiltre les secrets vers une infrastructure de command and control non encore publiquement identifiée, et — si l'utilisateur dispose des droits root — charge le rootkit eBPF dans le noyau. L'installation du package demandé se termine normalement, sans aucun signe visible de compromission.

La réponse de la communauté a été rapide. Dans les heures suivant la découverte, un outil de détection baptisé aur-malware-check a été publié sur GitHub (dépôt lenucksi/aur-malware-check), consolidant les Gists communautaires initiaux. Cet outil automatise la vérification des PKGBUILD installés contre la liste des packages compromis et recherche la présence d'atomic-lockfile ou js-digest dans les scripts de build. L'équipe Arch Linux a été notifiée et procède à la suppression des packages compromis du dépôt, mais les systèmes déjà infectés ne sont pas automatiquement assainis.

L'attribution de la campagne reste en cours. Le niveau de sophistication — notamment la maîtrise du développement eBPF kernel-level, combinée à la patience nécessaire pour adopter des dizaines de packages orphelins sans éveiller les soupçons — pointe vers un acteur structuré. La concentration exclusive sur les secrets développeur plutôt que sur des cibles financières suggère une opération d'espionnage industriel ou de préparation d'attaques supply chain en cascade. Selon BleepingComputer, « Atomic Arch » constitue l'incident supply chain le plus significatif jamais enregistré sur l'AUR.

Impact et exposition

Sont exposés tous les utilisateurs d'Arch Linux — particuliers, entreprises, environnements CI/CD — ayant installé l'un des packages compromis via un helper AUR entre mi-mai 2026 et le 12 juin 2026. Les images Docker basées sur Arch Linux utilisant des packages AUR sont également concernées. La compromission d'un seul poste de développement peut avoir des conséquences en cascade : un token GitHub valide suffit à accéder à des dépôts privés d'entreprise, à empoisonner des pipelines CI/CD, ou à injecter du code malveillant dans des projets open source publiés depuis la machine compromise.

Recommandations

  • Exécuter immédiatement aur-malware-check (GitHub : lenucksi/aur-malware-check) pour identifier les packages compromis installés
  • Révoquer et régénérer sans délai tous les tokens présents sur les machines à risque : GitHub Personal Access Token, npm, Docker Hub, HashiCorp Vault, clés SSH
  • Auditer les pipelines CI/CD ayant tourné sur des runners Arch Linux : vérifier l'intégrité des artefacts publiés depuis mai 2026
  • Scanner les systèmes avec Falco ou Tetragon pour détecter des programmes eBPF non autorisés (sudo bpftool prog list)
  • Renforcer la politique AUR : n'installer que des packages AUR avec PKGBUILD relus manuellement ou depuis des sources de confiance établies

Alerte critique

Tout poste de développement Arch Linux ayant utilisé yay ou paru depuis mi-mai 2026 doit être traité comme potentiellement compromis. La révocation immédiate de tous les tokens GitHub, clés SSH et secrets CI/CD est la priorité absolue avant toute autre action de remédiation.

Comment détecter et nettoyer un système infecté par Atomic Arch ?

En premier lieu, exécutez l'outil communautaire aur-malware-check (dépôt lenucksi sur GitHub). Il compare vos packages AUR installés contre la liste connue des 408 packages compromis. Recherchez ensuite la présence des packages npm atomic-lockfile et js-digest via npm list -g. Pour détecter le rootkit eBPF, exécutez sudo bpftool prog list et recherchez des programmes chargés avec des noms ou types suspects. La désinfection complète passe par la réinstallation du système depuis un médium sain, la révocation de tous les secrets exposés, et l'audit des commits GitHub effectués depuis la machine compromise.

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