Un AUR malveillant n’est pas un scénario de laboratoire. Arch Linux a désactivé temporairement l’adoption de paquets dans son Arch User Repository après une nouvelle vague de reprises suspectes et de commits malveillants. Le projet demande aussi de relire les PKGBUILD et les scripts d’installation avant toute mise à jour. Oui, même celui qui porte un nom connu depuis des années.
L’AUR vient de fermer une porte très pratique
L’AUR est le dépôt communautaire d’Arch Linux. Il ne distribue pas directement des paquets officiels : il héberge surtout des recettes de construction, les fameux PKGBUILD, qui indiquent à makepkg quoi télécharger, compiler et installer. Un utilisateur peut ensuite installer le paquet produit avec pacman, ou déléguer l’ensemble à un assistant AUR comme yay ou paru.
Ce modèle est puissant, mais il repose sur une règle simple : le contenu fourni par les utilisateurs n’est pas contrôlé comme un paquet officiel. ArchWiki le rappelle sans détour : un PKGBUILD peut exécuter des commandes sur la machine pendant la construction. Il faut donc lire les fichiers, vérifier les changements et comprendre les téléchargements déclenchés avant de lancer makepkg.
Le 30 juillet, Robin Candau, pour l’équipe DevOps d’Arch Linux, a annoncé que l’adoption de paquets était désactivée « en raison de l’afflux actuel d’adoptions malveillantes et de commits de suivi ». Le message officiel demande de signaler les événements suspects et les modifications douteuses. Un signalement de la communauté a déjà conduit à la suspension d’un compte créé avec une adresse électronique jetable, après l’adoption d’un paquet unique.
Le piège : voler une réputation plutôt qu’un nom
Une attaque par typosquatting publie un faux paquet au nom presque identique à l’original. C’est grossier, mais cela fonctionne encore. L’adoption malveillante est plus discrète : l’attaquant reprend un paquet abandonné qui possède déjà un nom crédible, un historique et parfois des utilisateurs.
L’intérêt est évident. Il n’a pas besoin de convaincre quelqu’un d’installer outil-super-securise-bin avec une faute de frappe. Il attend qu’un paquet orphelin soit disponible, récupère sa place dans l’AUR, puis pousse un changement dans le script de construction. Le nom reste familier ; le code exécuté ne l’est plus.
C’est précisément pour cela qu’Arch a aussi signalé des problèmes possibles pour créer des comptes, pousser des mises à jour et créer ou adopter des paquets. Le projet tente de stopper les modifications pendant qu’il traite les commits déjà injectés. La mesure est brutale, mais elle évite de laisser une fonctionnalité pratique servir de tapis roulant à des reprises automatisées.
Illustration générée par IA pour NumeriBrain.
Le danger démarre avant l’installation
Le point souvent mal compris, c’est que le risque ne commence pas forcément avec le binaire final. Il peut apparaître pendant la construction. Un PKGBUILD peut ajouter une dépendance inattendue, télécharger un fichier depuis une adresse inhabituelle, lancer un autre gestionnaire de paquets ou appeler un script d’installation avec des privilèges élevés.
Le précédent épisode « Atomic Arch », analysé par la Cloud Security Alliance, montre pourquoi les postes de développement intéressent les attaquants. Les secrets recherchés ne sont pas seulement les fichiers personnels : clés SSH, jetons GitHub, identifiants de registres de conteneurs, sessions de navigateurs, fichiers de configuration et accès aux services infonuagiques. Une machine Arch compromise peut donc devenir un tremplin vers un dépôt de code ou une chaîne d’intégration continue.
Le lien avec la vague actuelle doit rester précis : Arch confirme aujourd’hui le volume d’adoptions et de commits suspects, pas une liste complète de charges utiles ni un bilan définitif des machines touchées. Les détails techniques du précédent épisode ne doivent pas être recyclés comme s’ils décrivaient automatiquement chaque commit découvert cette semaine.
Ce que tu dois vérifier avant de relancer yay
Première règle : ne mets pas à jour machinalement un paquet AUR récemment adopté ou dont le mainteneur vient de changer. Consulte sa page, les commentaires et l’historique Git. Compare le dernier commit avec le précédent et ouvre chaque PKGBUILD, fichier .install et script associé.
Deuxième règle : cherche les commandes qui n’ont rien à faire là. Un téléchargement curl ou wget, un appel à npm, bun, pip ou un script shell obfusqué ne prouvent pas à eux seuls une compromission, mais ils méritent une explication claire. Si tu ne comprends pas une modification, ne construis pas le paquet. Un écran de terminal qui défile n’est pas une revue de code.
Troisième règle : traite les installations récentes comme un événement à documenter. Note les paquets construits, la date, le commit utilisé et les secrets accessibles sur la machine. Si un paquet identifié comme malveillant a réellement été exécuté, considère les jetons, clés et sessions présents comme potentiellement exposés. La réponse sérieuse passe par la rotation des secrets et, pour une machine très privilégiée, par une reconstruction depuis une source saine.
Arch demande officiellement de relire les PKGBUILD et les scripts d’installation, puis de signaler les commits suspects via aur-general. Ce n’est pas très automatisé, mais c’est cohérent avec le modèle de l’AUR : la communauté fournit les recettes, elle doit aussi surveiller ce qu’elles exécutent.
La confiance ne compile rien
L’AUR reste l’une des raisons pour lesquelles Arch est agréable à personnaliser. Mais un paquet connu n’est pas une preuve cryptographique de continuité, et un compteur de votes ne remplace pas un diff. En bloquant les adoptions, Arch reconnaît que la commodité avait créé un angle mort exploitable.
Pour l’instant, la meilleure protection tient en trois gestes peu sexy : vérifier le mainteneur, lire le changement et limiter les secrets disponibles pendant la construction. Le paquet peut avoir dix ans d’historique ; la ligne dangereuse, elle, peut n’avoir que cinq minutes.
Sources
Arch Linux, « Active AUR malicious packages incident » — https://archlinux.org/news/active-aur-malicious-packages-incident/ — annonce officielle et consignes aux utilisateurs.
Arch Linux AUR General, « AUR packages adoption disabled » — https://lists.archlinux.org/archives/list/aur-general%40lists.archlinux.org/thread/DRDEU3JUSC72CB265XHXPFA3DFSLXPBP/ — confirmation de la suspension le 30 juillet 2026.
ArchWiki, « Arch User Repository » — https://wiki.archlinux.org/title/Arch_User_Repository — fonctionnement et avertissements sur les PKGBUILD.
Cyber Security News, « Arch Linux Disables AUR Package Takeovers » — https://cybersecuritynews.com/arch-linux-disables-aur-package/ — contexte indépendant sur la vague de reprises.
Cloud Security Alliance, « Atomic Arch: AUR Supply Chain Attack » — https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/06/CSA_research_note_aur_supply_chain_ebpf_rootkit_20260614-csa-styled-2.pdf — analyse du précédent épisode, utilisée pour le contexte et explicitement distinguée de l’incident actuel.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet