Le 11 juin 2026, Sonatype a révélé une campagne de détournement de paquets dans l’Arch User Repository (AUR). Baptisée Atomic Arch, elle visait des paquets orphelins repris par de nouveaux comptes, puis modifiés pour installer une dépendance npm malveillante.
Sonatype estime qu’environ 1 500 paquets ont pu être concernés au fil de plusieurs vagues. Ce chiffre était encore présenté comme préliminaire dans son analyse. Arch Linux a confirmé un volume important d’adoptions et de mises à jour malveillantes sans publier de décompte définitif.
L’analyse statique du second étage montre des fonctions de collecte d’identifiants, d’anti-debugging et des références à eBPF pouvant servir à masquer des processus, fichiers ou connexions. Elle ne permet pas d’affirmer que toutes ces fonctions ont été exécutées sur chaque machine touchée.
Mise à jour du 28 août 2026 : le nombre de paquets est présenté comme une estimation, et les capacités eBPF comme des fonctions observées lors de l’analyse statique. La version initiale les décrivait trop directement comme un rootkit pleinement déployé.
En bref#
- Campagne Atomic Arch débutée le 11 juin 2026, découverte par Sonatype.
- Environ 1 500 paquets potentiellement concernés selon l’estimation publiée par Sonatype pendant l’enquête.
- Mécanisme : adoption de paquets orphelins, modification du PKGBUILD pour exécuter
npm install atomic-lockfile(oujs-digest,lockfile-js). - Payload : binaire natif avec collecte d’identifiants et capacités eBPF de type rootkit observées par analyse statique.
- 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. Les statistiques AUR indiquaient alors environ 69 Package Maintainers. Ce nombre ne décrit pas à lui seul les droits d’administration ni l’ensemble des personnes qui contribuent à la modération.
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#
Les vagues documentées suivent un schéma en trois étapes :
- Adoption de paquets orphelins via le processus standard de l’AUR
- Modification du PKGBUILD ou du fichier
.installpour ajouter une commande exécutée en post-install - 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 chalkExé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 initialejs-digest- variante identifiée le 12 juinlockfile-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 contient des fonctions associées à la collecte d’identifiants, à l’exfiltration et à la réduction de visibilité.
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.
Capacités eBPF de type rootkit#
L’analyse statique révèle des références à un programme eBPF et aux API suivantes :
bpf_object__loadbpf_program__attachbpf_map__pin
Le code analysé contient des fonctions associées au masquage de processus, de fichiers et d’activité réseau, notamment autour de getdents64(). Les structures identifiées dans le binaire incluent :
hidden_pids- processus masquéshidden_names- noms de fichiers cachéshidden_inodes- inodes masqués
Le binaire contient aussi des mécanismes anti-debug via PTRACE_ATTACH et PTRACE_SEIZE.
Portée de ces capacités#
Lorsqu’il obtient les privilèges nécessaires, le payload peut tenter de :
- masquer sa présence dans
/proc - intercepter et filtrer les connexions réseau
- épingler des objets eBPF dans
bpffspour les maintenir après la fin du processus qui les a chargés - rendre la détection par les outils de monitoring standard très difficile
Un programme eBPF épinglé ne survit pas à lui seul à un redémarrage. Une persistance après reboot exige un mécanisme supplémentaire de rechargement. Si le payload a été exécuté avec des privilèges élevés, l’hôte doit néanmoins être considéré comme non fiable et reconstruit depuis une source saine.
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 -QqmIdentifier 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/nullDé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 -iDétection eBPF#
sudo bpftool prog list
sudo ls /sys/fs/bpf/Des programmes eBPF inattendus sont suspects.
Correctifs et mitigations#
Actions immédiates#
- Mettre à jour les paquets AUR en vérifiant chaque PKGBUILD avant installation
- Identifier les machines Arch dans votre environnement
- Faire l’inventaire des paquets AUR installés et les croiser avec les listes de paquets compromis publiées par la communauté
- Si un paquet identifié comme malveillant a exécuté son script, considérer la machine comme compromise
En cas de compromission suspectée#
- Réinstaller le système à partir d’un média de confiance. Ne pas faire confiance à une simple désinfection
- Rotation de tous les secrets : clés SSH, tokens GitHub/npm, clés API cloud, tokens Vault
- Invalider les sessions navigateur et régénérer les passkeys
- Révoquer les tokens CI/CD qui étaient stockés sur la machine
- 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 ?
- Quels moyens donner à la modération d’un dépôt dépassant 100 000 paquets ?
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 montre qu’une reprise de maintenance peut devenir un vecteur de compromission de la chaîne logicielle lorsqu’elle conserve le nom, l’historique et la confiance associés au paquet.
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.
Le mécanisme exact est propre à l’AUR, mais la leçon s’applique aux écosystèmes où un projet abandonné peut changer de mainteneur : le nom et l’historique ne remplacent pas la revue du code exécuté à l’installation.
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#
Sources vérifiées le 28 août 2026 :
