Arch Linux : l’AUR se fait véroler, et ça pique fort pour les amateurs de paquets “magiques”

Vous aimez Arch Linux, vous aimez l’AUR, vous aimez taper un petit yay -S le-paquet-qui-va-bien sans trop vous poser de questions ? Mauvaise nouvelle : cette semaine, l’Arch User Repository a pris une belle claque côté sécurité.

Et pas une petite alerte anecdotique sur trois paquets obscurs téléchargés par deux barbus dans une cave. Non, là on parle d’une campagne de compromission massive visant des paquets AUR, avec plusieurs centaines de paquets repérés au départ, puis un compteur qui aurait grimpé autour de 1 500 paquets touchés ou suspects selon les analyses en cours.

Bref : l’AUR vient de rappeler à tout le monde une règle simple que beaucoup connaissent… mais que pas mal oublient quand ça va vite : l’AUR, ce n’est pas le dépôt officiel d’Arch Linux.

L’AUR, ce supermarché communautaire où il faut lire les étiquettes

Pour ceux qui débarquent, l’AUR, c’est un peu la caverne d’Ali Baba d’Arch Linux. On y trouve des logiciels absents des dépôts officiels, des versions Git, des binaires propriétaires, des outils pratiques, des vieilleries maintenues par miracle, et parfois exactement le paquet qu’il vous faut pour éviter de compiler à la main pendant trois heures.

Sauf que l’AUR repose sur des paquets communautaires. En gros, vous récupérez un PKGBUILD, vous le construisez localement, et vous faites confiance au script qui va aller chercher les sources, compiler, installer, patcher, bidouiller.

Et c’est précisément là que le bât blesse.

Dans cette attaque, des acteurs malveillants auraient ciblé des paquets orphelins ou peu maintenus. Ils les adoptent, modifient le PKGBUILD ou les scripts d’installation, puis glissent une dépendance malveillante. Vu de loin, le paquet garde son nom, son historique, sa petite réputation tranquille. Vu de près, il vient de se transformer en cheval de Troie.

Pas besoin de hacker toute l’infrastructure Arch. Il suffit parfois d’hériter de la confiance déjà installée.

“Atomic Arch” : le joli nom pour une vilaine campagne

La campagne a été surnommée “Atomic Arch” par Sonatype. Le principe est assez sournois : certains paquets modifiés appelaient une dépendance npm malveillante comme atomic-lockfile, avec d’autres variantes repérées ensuite, dont js-digest ou lockfile-js. Une autre vague aurait aussi utilisé Bun plutôt que npm, avec davantage d’obfuscation pour planquer l’action réelle du script.

Traduction en langage humain : vous installez ou mettez à jour un paquet AUR qui a l’air normal, et pendant l’installation, il va discrètement chercher un composant vérolé ailleurs. Ce composant peut ensuite déposer un binaire Linux conçu pour voler des informations sensibles.

Et quand on parle d’informations sensibles, ce n’est pas juste le nom de votre fond d’écran KDE. Les analyses évoquent des cibles comme les identifiants GitHub, les clés SSH, les tokens Vault, les cookies de navigateurs, les données Slack, Discord, Teams ou Telegram. Le genre de petites choses qui intéressent beaucoup les attaquants, surtout sur les machines de développeurs.

Cerise moisie sur le gâteau : certains rapports parlent aussi de capacités proches d’un rootkit eBPF si le malware obtient les droits suffisants. Là, on sort du simple paquet foireux et on entre dans le “ta machine mérite peut-être une réinstallation propre”.

Non, Arch Linux n’est pas “cassé”

Avant de sortir les fourches : non, ça ne veut pas dire que les dépôts officiels Arch Linux sont compromis.

Le problème touche l’AUR, c’est-à-dire le dépôt communautaire. C’est une nuance importante. Les paquets officiels Arch passent par un autre circuit, avec des mainteneurs identifiés et un niveau de contrôle différent.

Mais ça ne veut pas dire que l’incident est anodin. L’AUR fait partie de l’expérience Arch pour énormément d’utilisateurs. Soyons honnêtes : beaucoup installent yay ou paru très vite après leur première installation, parce que l’AUR est pratique, complet et souvent indispensable pour certains logiciels.

Le souci, c’est que cette praticité a un prix : il faut lire ce qu’on installe.

Oui, je sais. Personne n’a envie de relire un PKGBUILD à 23 h 47 juste pour mettre à jour un thème GTK ou un vieux driver exotique. Mais c’est exactement ce que recommande Arch depuis toujours : vérifier les fichiers de build et les scripts d’installation, surtout lors des mises à jour.

Ce que doivent faire les utilisateurs Arch maintenant

Si vous utilisez Arch Linux ou une distribution basée sur Arch avec des paquets AUR, le bon réflexe est de ne pas paniquer, mais de vérifier sérieusement.

Commencez par regarder les paquets AUR installés récemment ou mis à jour depuis le 11 juin 2026. Consultez les listes communautaires et les alertes publiées autour de l’incident. Vérifiez si l’un de vos paquets apparaît dans les listes de paquets touchés ou suspects.

Ensuite, inspectez votre historique d’installation et de mise à jour. Si un paquet AUR a soudainement ajouté npm, Bun, un script post-install douteux ou une dépendance qui n’a rien à faire là, méfiance.

Si vous pensez avoir installé un paquet compromis, ne vous contentez pas de le supprimer. Un malware qui a eu l’occasion de s’exécuter peut avoir déjà récupéré des secrets ou installé de la persistance. Dans ce cas, il faut envisager une rotation des mots de passe, tokens, clés SSH, accès GitHub/GitLab, clés API, sessions cloud, etc.

Et si le poste est utilisé pour du développement professionnel, de la CI/CD, des dépôts privés ou des accès sensibles, traitez ça comme un vrai incident de sécurité. Pas comme une simple “mise à jour qui sent bizarre”.

Les bonnes habitudes à reprendre avec l’AUR

L’AUR reste un outil génial. Mais il ne faut pas l’utiliser comme si c’était un App Store avec validation magique par une armée de lutins open source.

Quelques réflexes simples peuvent éviter pas mal de dégâts :

– Lire les PKGBUILD avant installation et mise à jour

– Se méfier des paquets orphelins fraîchement adoptés

– Vérifier les changements de mainteneur

– Regarder les dépendances ajoutées, surtout si elles semblent hors sujet

– Éviter les paquets AUR inutiles “juste pour tester”

– Préférer les dépôts officiels quand c’est possible

– Utiliser l’AUR dans un environnement isolé quand on installe des choses exotiques

– Ne jamais lancer aveuglément une commande trouvée dans un commentaire ou un gist random

Le problème n’est pas l’AUR en soi. Le problème, c’est l’automatisme : installer, valider, compiler, suivant, terminé. Ce confort est précisément ce que les attaquants exploitent.

Une attaque qui dépasse Arch Linux

Ce qui se passe avec l’AUR n’est pas juste “un problème Arch”. C’est un énième rappel que la supply chain open source est devenue une cible de choix.

npm, PyPI, RubyGems, extensions de navigateur, images Docker, paquets communautaires… partout où l’on peut glisser un bout de code dans une chaîne de confiance, quelqu’un essaiera tôt ou tard.

Et ici, l’attaque est intéressante parce qu’elle ne casse pas la porte d’entrée principale. Elle passe par la porte de service : les paquets abandonnés, les mainteneurs absents, les scripts que plus personne ne relit vraiment.

C’est moins spectaculaire qu’un “hack massif d’Arch Linux”, mais c’est probablement plus inquiétant. Parce que ça montre que la confiance accumulée par un projet peut être récupérée, recyclée, puis retournée contre ses utilisateurs.

L’AUR reste puissant, mais pas magique

Arch Linux n’est pas mort, l’AUR ne doit pas forcément finir au bûcher, et les utilisateurs Linux ne doivent pas retourner sous Windows en pleurant dans leur ISO.

Mais cet incident doit servir de rappel brutal : l’AUR est puissant parce qu’il est ouvert. Et parce qu’il est ouvert, il demande une hygiène minimale.

Si vous utilisez Arch, continuez à profiter de l’AUR, mais arrêtez de cliquer sur “oui” comme si vous installiez une appli météo sur Android. Lisez les scripts. Vérifiez les mainteneurs. Méfiez-vous des paquets orphelins. Et quand un paquet audio ou un thème d’icônes se met soudainement à tirer du npm ou du Bun, posez-vous deux secondes.

Parce qu’au final, sur Arch comme ailleurs, le vrai pare-feu se trouve souvent entre la chaise et le clavier.