Campagne Atomic Arch : 1 500 paquets AUR détournés avec un infostealer et un rootkit eBPF

Le 11 juin 2026, les équipes de sécurité de Sonatype ont révélé une campagne massive de détournement de paquets dans l’Arch User Repository (AUR). Baptisée Atomic Arch, l’attaque a rapidement dépassé les premières estimations : de 400 paquets compromis le premier jour, le nombre est monté à plus de 1 500 en 48 heures.

Des chercheurs identifient désormais jusqu’à 1 900 paquets orphelins adoptés et modifiés. L’attaque automatisée injecte un credential stealer en Rust avec capacités rootkit via eBPF, ciblant SSH keys, tokens cloud, sessions navigateur et identifiants de messagerie.

Pour l’écosystème open source, cet incident dépasse largement Arch Linux. C’est le premier cas documenté d’une campagne industrialisée exploitant le mécanisme d’adoption des paquets orphelins à grande échelle.

En bref

#

• Campagne Atomic Arch débutée le 11 juin 2026, découverte par Sonatype.
• 1 500+ paquets AUR compromis à date, potentiellement 1 900+.
• Mécanisme : adoption de paquets orphelins, modification du PKGBUILD pour exécuter npm install atomic-lockfile (ou js-digest, lockfile-js).
• Payload : binaire Rust avec credential stealer + rootkit eBPF (peut masquer processus, fichiers et connexions réseau).
• Cibles principales : clés SSH, tokens GitHub, npm, cloud (AWS/GCP/Azure), sessions Discord/Slack/Teams, cookies navigateur.
• L’outil d’attaque serait automatisé, codé en Rust selon certaines sources.
• Arch Linux a confirmé l’incident le 12 juin 2026 et travaille sur des contre-mesures.
• Risque maximal sur les postes de travail Arch exposés à AUR. Impact indirect possible sur les environnements CI/CD utilisant des runners Arch.

Contexte : comment AUR fonctionne

#

L’Arch User Repository est un dépôt communautaire qui contient, au 14 juin 2026, plus de 107 000 paquets. Parmi eux, 13 259 paquets orphelins, des paquets dont le mainteneur d’origine n’assure plus le suivi.

Ces paquets orphelins sont la cible principale de l’attaque. Le mécanisme est simple : n’importe quel utilisateur peut demander l’adoption d’un paquet orphelin. Si la demande est acceptée, le nouveau mainteneur obtient un contrôle complet sur le PKGBUILD et les fichiers d’installation associés.

Le système repose sur la confiance et le bénévolat. L’équipe AUR compte environ 69 personnes disposant de droits d’administration sur l’ensemble du dépôt. C’est trop peu pour superviser efficacement 107 000 paquets.

AVERTISSEMENT : Les paquets AUR sont des contenus créés par les utilisateurs.
Toute utilisation des fichiers fournis se fait à vos propres risques.

Cet avertissement, présent sur chaque page de paquet AUR, est aussi un constat : il n’y a pas de validation systématique.

Le mécanisme de l’attaque

#

Atomic Arch suit un schéma en trois étapes, parfaitement reproductible et automatisable :

1. Adoption de paquets orphelins via le processus standard de l’AUR
2. Modification du PKGBUILD ou du fichier .install pour ajouter une commande exécutée en post-install
3. Exécution d’une dépendance npm malveillante qui télécharge et lance le payload final

La ligne injectée ressemble à ceci :

npm install atomic-lockfile minimist chalk

Exécutée pendant l’installation du paquet AUR, cette commande télécharge le paquet npm atomic-lockfile depuis le registre officiel npm. Le package.json d’atomic-lockfile contient un script preinstall qui lance un binaire natif Linux compilé en Rust.

Les chercheurs ont identifié plusieurs variants :

• atomic-lockfile - la version initiale
• js-digest - variante identifiée le 12 juin
• lockfile-js - seconde variante
• Certains paquets utilisaient Bun plutôt que npm comme mécanisme d’installation

L’attaque est montée en puissance très vite. Ce qui a commencé comme une dizaine de paquets est passé à 400, puis 1 500+ en l’espace de 24 heures.

Analyse du payload

#

Le binaire livré par le paquet npm malveillant est un infostealer complet avec des capacités avancées de persistence et d’évasion.

Credential stealer

#

Les cibles identifiées dans le binaire :

• Clés SSH (id_rsa, id_ed25519, known_hosts)
• Tokens GitHub et npm
• Tokens cloud : AWS, GCP, Azure
• Sessions navigateur : cookies, session tokens (Chrome, Firefox, Chromium)
• Messagerie : Discord, Slack, Microsoft Teams, Telegram
• HashiCorp Vault tokens
• Docker / Podman credentials

Le binaire utilise les sockets de diagnostic Linux (NETLINK_SOCK_DIAG) pour intercepter les connexions actives. Il dispose aussi de capacités d’upload HTTP multipart (POST /upload) vers un serveur C2.

Rootkit eBPF

#

La partie la plus sophistiquée du payload est un rootkit basé sur eBPF (extended Berkeley Packet Filter). L’analyse statique révèle l’utilisation de :

• bpf_object__load
• bpf_program__attach
• bpf_map__pin

Le rootkit peut cacher des processus, des fichiers et des connexions réseau en hookant l’appel système getdents64() (lecture des répertoires). Les structures identifiées dans le binaire incluent :

• hidden_pids - processus masqués
• hidden_names - noms de fichiers cachés
• hidden_inodes - inodes masqués

Le binaire contient aussi des mécanismes anti-debug via PTRACE_ATTACH et PTRACE_SEIZE.

Capacités rootkit

#

Lorsqu’il s’exécute avec les privilèges root, le payload peut :

• masquer sa présence dans /proc
• intercepter et filtrer les connexions réseau
• persister via des mécanismes eBPF même après redémarrage
• rendre la détection par les outils de monitoring standard très difficile

Un hôte compromis doit être traité comme entièrement infecté : une analyse antivirus ne suffit pas, une réinstallation complète à partir d’un support de confiance est nécessaire.

Qui est concerné

#

Impact direct

#

• Tous les utilisateurs d’Arch Linux et des distributions dérivées (EndeavourOS, Manjaro avec AUR activé)
• Postes de développement sous Arch
• Runners CI/CD auto-hébergés sous Arch qui installent des paquets AUR
• Utilisateurs de WSL2 avec une distribution Arch

Impact indirect

#

Les tokens et credentials exfiltrés peuvent permettre un pivot vers d’autres systèmes : dépôts GitHub, registres npm, environnements cloud. Un poste de développeur Arch compromis peut devenir un point d’entrée vers des infrastructures non-Arch.

Qui n’est pas concerné par ce vecteur

#

• Les runners GitHub hébergés par GitHub (Ubuntu, Windows, macOS) n’utilisent pas AUR
• Les machines Debian, Ubuntu, RHEL, Fedora sans couche Arch
• Les postes macOS ou Windows sans Arch en VM/WSL

Vérifier son exposition

#

Lister les paquets AUR installés

#

pacman -Qqm

Identifier les paquets orphelins adoptés récemment

#

Il n’existe pas de commande unique pour croiser les dates d’adoption. La méthode manuelle reste la consultation du PKGBUILD sur le site AUR pour chaque paquet suspect. Avec yay, on vérifie les informations d’un paquet :

yay -Qi <paquet>

Vérifier les fichiers d’installation

#

Les scripts .install des paquets AUR sont dans le cache de construction local (généralement ~/.cache/yay/). Cherchez des appels à npm install, bun install, ou des commandes inhabituelles :

grep -r "npm install\|bun install" ~/.cache/yay/*/PKGBUILD ~/.cache/yay/*/.install 2>/dev/null

Détection réseau

#

Surveillez les connexions sortantes inhabituelles, notamment vers des IP inconnues ou des services de partage de fichiers (pastebin, file.io, etc.) :

sudo ss -tupn
sudo lsof -i

Détection eBPF

#

sudo bpftool prog list
sudo ls /sys/fs/bpf/

Des programmes eBPF inattendus sont suspects.

Correctifs et mitigations

#

Actions immédiates

#

1. Mettre à jour les paquets AUR en vérifiant chaque PKGBUILD avant installation
2. Identifier les machines Arch dans votre environnement
3. Faire l’inventaire des paquets AUR installés et les croiser avec les listes de paquets compromis publiées par la communauté
4. Si un paquet compromis a été installé ou mis à jour depuis début juin, considérer la machine comme compromise

En cas de compromission suspectée

#

1. Réinstaller le système à partir d’un média de confiance. Ne pas faire confiance à une simple désinfection
2. Rotation de tous les secrets : clés SSH, tokens GitHub/npm, clés API cloud, tokens Vault
3. Invalider les sessions navigateur et régénérer les passkeys
4. Révoquer les tokens CI/CD qui étaient stockés sur la machine
5. Vérifier les logs des services tiers (GitHub audit log, cloud trail, etc.) pour détecter des accès non autorisés

Recommandations à long terme

#

• Limiter le nombre de paquets AUR : moins il y en a, plus la surface d’attaque est réduite
• Privilégier les paquets que vous maintenez vous-même ou ceux de mainteneurs connus
• Toujours lire le PKGBUILD avant d’installer ou de mettre à jour un paquet AUR (yay et paru le proposent par défaut)
• Ne pas exécuter yay -Syu ou paru -Syu sans surveillance pendant la période d’instabilité
• Envisager des dépôts alternatifs comme Chaotic-AUR qui applique des vérifications supplémentaires (mais cela déplace la confiance, ne la supprime pas)

Ce que ça change pour l’écosystème

#

Atomic Arch pose des questions structurelles que l’AUR n’avait pas eu à affronter à cette échelle :

• Faut-il imposer un délai de caution avant qu’un nouveau compte puisse adopter des paquets orphelins ?
• Faut-il mettre AUR en lecture seule pendant les attaques ?
• Comment détecter automatiquement les PKGBUILD modifiés frauduleusement ?
• Qui paie pour la modération de 107 000 paquets avec seulement 69 administrateurs ?

La réponse n’est pas technique. C’est un problème de gouvernance et de ressources humaines. AUR repose sur le bénévolat. Atomic Arch montre qu’un modèle non modéré peut être exploité de manière industrielle.

Les distributions dérivées comme Garuda, qui maintiennent leurs propres dépôts tiers basés sur AUR, sont confrontées à la même question : comment garantir qu’aucun paquet détourné ne passe entre les mailles du filet ?

Conclusion

#

Atomic Arch n’est pas un simple incident de plus dans la longue liste des attaques supply chain. C’est la première démonstration à grande échelle que le détournement de paquets orphelins peut être automatisé et rentable pour un attaquant.

Le modèle de confiance implicite d’AUR, qui fonctionnait depuis 20 ans, montre ses limites. Les utilisateurs d’Arch doivent adapter leurs pratiques : moins de paquets AUR, plus de vigilance sur chaque mise à jour, et une hygiène de secrets renforcée.

Pour le reste de l’écosystème, c’est un signal. Homebrew (macOS), les PPA Ubuntu, ou tout dépôt communautaire avec transfert de propriété automatique est vulnérable au même schéma.

Remerciements

#

Merci à @Fritange@maly.io pour la recommandation du dépôt lenucksi/aur-malware-check, un outil communautaire pratique pour détecter les paquets compromis sur son système.

Sources

#

• Arch Linux - Active AUR malicious packages incident
• StepSecurity - 400+ AUR Packages Hijacked: Atomic Arch Campaign
• Sonatype - Atomic Arch: Attackers Hijack Trusted AUR Packages
• Phoronix - Arch Linux AUR Sees More Than 400 Packages Compromised
• Phoronix - AUR Compromise Grows To More Than 1,500 Packages
• Frederic Bezies - Point sur l’attaque AUR
• The Cyber Sec Guru - Atomic Arch: 900+ AUR Packages Backdoored with eBPF Rootkit
• Privacy Guides - Around 1,500 AUR Packages Compromised
• AUR - Arch User Repository