Atomic Arch : l'adoption de paquets AUR suspendue après une troisième vague de prise de contrôle

Rapport CTI technique du 1 août 2026

Résumé exécutif

Le 30 juillet 2026, l'équipe DevOps d'Arch Linux a désactivé la fonctionnalité d'adoption de paquets sur l'Arch User Repository après une nouvelle vague de prises de contrôle malveillantes visant des paquets orphelins. Cette décision fait suite à la campagne baptisée Atomic Arch, révélée en juin 2026, où des attaquants avaient adopté plus de 400 paquets communautaires abandonnés pour y injecter une dépendance malveillante déclenchant, à l'installation, un voleur de identifiants compilé en Rust ciblant les clés SSH, les jetons GitHub et npm, les identifiants cloud et les sessions de messagerie d'équipe stockées sur la machine du développeur.

Le mécanisme d'attaque exploite un point de confiance structurel du modèle AUR : quand un mainteneur abandonne un paquet, un autre utilisateur peut en hériter le nom et la réputation accumulée, sans que le contenu du PKGBUILD ne soit revu de façon centralisée avant chaque build. Les décomptes communautaires publiés après la divulgation initiale évoquent un périmètre nettement plus large que les 400 paquets annoncés en juin, certaines listes consolidées par la communauté approchant les 1 900 noms de paquets touchés à un moment ou un autre de la campagne ; ce chiffre reste une estimation communautaire, non confirmée officiellement par l'équipe Arch Linux dans les sources consultées pour cette fiche. Trois vagues de compromission distinctes ont été observées entre juin et fin juillet, la dernière ayant motivé la suspension pure et simple de l'adoption de paquets.

Chronologie

Date	Événement
Vers le 10-11 juin 2026	Première vague : injection de la dépendance malveillante atomic-lockfile via des hooks PKGBUILD sur des paquets orphelins adoptés
Vers le 12 juin 2026	Deuxième vague : bascule vers bun add avec les paquets js-digest et lockfile-js, hook preinstall pointant vers ./lib/install-deps.mjs
11-12 juin 2026	Divulgation publique par les chercheurs Sonatype et la communauté Arch Linux, plus de 400 paquets recensés à ce stade
Fin juillet 2026	Troisième vague de prises de contrôle et de commits malveillants ciblant à nouveau des paquets orphelins ou abandonnés
30 juillet 2026	Robin Candau, au nom de l'équipe DevOps d'Arch Linux, annonce la désactivation temporaire de l'adoption de paquets sur l'AUR

Fiche vulnérabilité (format fiche CTI)

Sans CVE : abus du mécanisme d'adoption de paquets AUR, pas de faille logicielle isolée

Il ne s'agit pas de l'exploitation d'un bug dans un binaire mais du détournement d'une fonctionnalité légitime de gouvernance communautaire. L'AUR permet à tout utilisateur enregistré de demander l'adoption d'un paquet dont le mainteneur original est inactif, héritant immédiatement du nom du paquet et de la confiance qui s'y attache auprès des utilisateurs existants. Les attaquants ont ciblé spécifiquement des paquets avec un historique d'usage légitime plutôt que de publier de nouveaux paquets sous des noms proches de paquets connus, une approche qui rend la détection par vigilance humaine nettement plus difficile qu'un typosquatting classique.

Conditions d'exploitation : disposer d'un compte AUR enregistré, cibler un paquet marqué comme orphelin, obtenir son adoption, puis modifier le PKGBUILD ou les scripts .install pour ajouter une étape post-installation invoquant un gestionnaire de paquets Node (npm ou bun). L'exécution effective du malware ne se produit que lorsqu'un utilisateur installe ou met à jour le paquet compromis via makepkg ou un helper AUR, ce qui exécute le code avec les mêmes privilèges que le processus de build, potentiellement root selon la configuration du système. PoC disponible : oui, plusieurs chercheurs et projets communautaires (dont un outil de détection publié sur GitHub par jasonherald) ont documenté et republié les indicateurs de compromission. Patch/mitigation : suppression des paquets malveillants identifiés par l'équipe Arch Linux, purge de plus de 1 900 paquets signalés en juin, et désormais suspension complète du mécanisme d'adoption depuis le 30 juillet en attendant une révision du processus.

Diagramme de la chaîne d'attaque

Chaîne de compromission de la campagne Atomic Arch sur l'AUR
Reconstruction à partir des analyses Sonatype, StepSecurity et de la liste de diffusion Arch Linux. Légende : trois vagues successives d'adoption de paquets orphelins, injection de dépendance malveillante, exécution du voleur d'identifiants au moment du build.

Analyse technique

Étape 1 : ciblage et adoption de paquets orphelins

Les attaquants identifient des paquets AUR marqués comme orphelins, c'est-à-dire sans mainteneur actif, mais conservant une base d'utilisateurs établie. Ils soumettent une demande d'adoption via le mécanisme standard de l'AUR, opération qui ne déclenche aucune revue de sécurité automatique du contenu existant du paquet.

Étape 2 : injection d'une dépendance malveillante dans le PKGBUILD

Une fois l'adoption effective, les attaquants modifient le PKGBUILD ou les scripts .install associés pour ajouter une étape d'installation d'un paquet Node malveillant. La première vague utilisait npm install atomic-lockfile, la deuxième bun add js-digest ou lockfile-js, chaque paquet npm/bun malveillant embarquant un hook de cycle de vie preinstall ou postinstall pointant vers un script interne au paquet.

Étape 3 : exécution silencieuse au moment du build

Quand un utilisateur installe ou met à jour le paquet AUR compromis, makepkg exécute automatiquement les étapes du PKGBUILD, y compris l'installation de la dépendance Node malveillante. Le hook de cycle de vie de cette dépendance déclenche alors l'exécution d'un binaire ELF64 compilé en Rust et stripé, conçu selon une architecture asynchrone à machine d'états, sans qu'aucune alerte ne soit visible pour l'utilisateur au-delà du temps de build légèrement allongé.

Étape 4 : collecte ciblée d'identifiants de développeur

Le binaire ELF cible spécifiquement les actifs à forte valeur présents sur une machine de développement ou un runner CI : cookies et jetons de session de navigateur, clés SSH et fichier known_hosts, jetons GitHub et npm, identifiants Docker/Podman et clés d'accès cloud, ainsi que les sessions Slack, Discord et Teams stockées localement. Sur un système où le build s'exécute avec des privilèges root, le malware tente en complément une persistance de type rootkit basée sur eBPF pour masquer ses processus et son activité fichier.

Étape 5 : exfiltration vers une infrastructure Tor et de secours

L'exfiltration primaire s'effectue vers un service caché Tor via une requête POST /api/agent, un canal difficile à bloquer par filtrage IP classique. Un canal secondaire observé utilise temp.sh, un service public de partage de fichiers, via une requête POST /upload, probablement comme solution de repli si la connectivité Tor est bloquée sur l'hôte compromis.

Indicateurs de compromission

Type	Valeur
Dépendances npm malveillantes (vague 1)	atomic-lockfile
Dépendances malveillantes (vague 2, bun)	js-digest, lockfile-js
Hook de cycle de vie observé	preinstall pointant vers ./src/hooks/deps ou ./lib/install-deps.mjs
Type de payload	Binaire ELF64, Rust compilé et stripé, architecture async state machine
Canal d'exfiltration primaire	Service caché Tor, requête POST /api/agent
Canal d'exfiltration secondaire	temp.sh, requête POST /upload
Persistance additionnelle	Tentative de rootkit basé sur eBPF si exécution avec privilèges root
Périmètre annoncé publiquement (juin 2026)	Plus de 400 paquets AUR compromis

Le chiffre de « près de 1 900 » paquets concernés à un moment ou un autre de la campagne provient de listes consolidées par la communauté et non d'une annonce officielle d'Arch Linux ; il est rapporté ici comme estimation à prendre avec prudence plutôt que comme total confirmé.

MITRE ATT&CK

Aucune cartographie officielle n'a été publiée par l'équipe Arch Linux. La table suivante est une lecture technique construite à partir des analyses Sonatype et StepSecurity, pas une attribution vendeur formelle.

Tactique	Technique	ID	Justification
Initial Access	Compromission de dépendances et d'outils de développement	T1195.001	Prise de contrôle de paquets AUR légitimes puis injection de dépendance Node malveillante
Execution	Interpréteur de commandes et de scripts	T1059	Exécution du PKGBUILD et des hooks npm/bun au moment du build
Credential Access	Identifiants dans des fichiers	T1552.001	Vol des clés SSH, known_hosts et jetons stockés localement
Credential Access	Identifiants de navigateur	T1555.003	Extraction des cookies et jetons de session de navigateur
Defense Evasion / Persistence	Rootkit	T1014	Tentative de dissimulation via un rootkit eBPF sur les hôtes compromis avec privilèges root
Exfiltration	Exfiltration via un service applicatif tiers	T1567	Envoi des données volées vers un service caché Tor et vers temp.sh

Remédiation : checklist opérationnelle

Recenser tous les postes développeur et runners CI/CD basés sur Arch Linux ou dérivés (EndeavourOS, Manjaro) ayant installé ou mis à jour un paquet AUR depuis début juin 2026.
Croiser l'historique d'installation AUR de ces machines avec les listes communautaires de paquets compromis publiées après la divulgation.
Considérer comme compromise toute machine ayant exécuté un build AUR malveillant avec privilèges root : réinstallation complète depuis un support de confiance, pas de simple scan antivirus.
Faire tourner immédiatement l'ensemble des secrets exposés sur les machines potentiellement touchées : clés SSH, jetons GitHub et npm, clés d'accès cloud, jetons Vault, sessions SSO.
Bloquer en sortie les connexions vers les nœuds de sortie Tor et vers temp.sh depuis les runners de build et les postes de développement, sauf besoin métier explicite.
Mettre en place une surveillance comportementale des étapes de build (appels réseau inattendus, création de processus enfants inhabituels, unités systemd ou objets eBPF non attendus).
Documenter et limiter l'usage de l'AUR aux seuls paquets strictement nécessaires, avec revue manuelle du PKGBUILD avant toute installation ou mise à jour, tant que le mécanisme d'adoption reste suspendu.
Surveiller les annonces de l'équipe Arch Linux concernant la reprise de l'adoption de paquets et les éventuelles mesures de revue introduites à cette occasion.