Depuis deux ou trois jours – en ce 14 juin 2026 – le service communautaire AUR subit une attaque assez puissant. On est passé d’environ 400 à plus de 1500 (en l’espace d’une journée) à environ 1900 si on en croit un des commentaires sur la vidéo du Lunduke Journal :
Il y a une adoption massive de paquets orphelins et dans le fichier install fourni, une ligne exécute une commande npm pour installer une charge malveillante, comme un keylogger ou un info stealer. Toujours selon la vidéo du Lunduke Journal, ce serait un outil codé en rust qui automatiserait l’attaque.
J’ignore où il a trouvé l’information, mais si c’est le cas, ça prouve qu’on peut tout faire avec du Rust, même une implémentation baclée et incomplète du protocole X11. Mais je m’éloigne du cœur du sujet, revenons-y donc.
Déjà, il ne faut pas oublier une chose. AUR est un dépôt communautaire de plus de 107 000 paquets au 14 juin 2026. Dans le lot, il y a 13259 paquets orphelins pouvant potentiellement être utilisés à des fins malicieuses. Et pour gérer tout cela – autant que faire ce peut – 69 personnes qui ont tous les droits dessus.
Autant essayer de nettoyer les écuries d’Augias, ce sera plus simple. Sur les listes de publications liées à AUR, de nombreuses propositions ont été faites, comme mettre AUR en lecture seulement le temps que l’attaque se termine. Mettre un tampon temporel d’une semaine pour qu’un compte nouvellement créé ne puisse pas adopter sauvagement des paquets. Des scripts ont été proposés pour détecter les paquets modifiés frauduleusement. Bref, ça ne chôme pas, et ça fait plaisir à voir.
Cependant, un point semble être oublié par pas mal de personnes : on installe des paquets AUR à nos propres risques. C’est écrit en toutes lettres :
DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk.
Ce qui donne traduit :
AVERTISSEMENT : Les paquets AUR sont des contenus créés par les utilisateurs. Toute utilisation des fichiers fournis se fait à vos propres risques.
J’ai connu des périodes durant mon époque d’Archlinuxien à poil dur des pointes à 30 paquets AUR. Sur mon portable avec LXQt, je n’en ai plus que 8 paquets. Dedans, 5 que je maintiens et 3 paquets sérieux : octopi et son indispensable qt-sudo, yay. Aucun paquet plus ou moins nichesques, plus ou moins bizarre.
Je ne prétends pas qu’AUR soit parfait. Mais si on prend la précaution de lire le PKGBUILD et le fichier install – s’il existe – avant de passer à l’installation comme le propose les enrobeurs d’AUR comme yay ou paru, on limite franchement la casse.
Reste une question en suspend : comment fait l’équipe de Garuda pour s’assurer que son dépôt tiers ne contient pas de paquets avec une charge vérolée à l’intérieur ? Si vous avez la réponse, je suis preneur.
Sur ce, bonne fin de journée.
Même si AUR prévient clairement l’utilisateur des dangers éventuels, il faut quand même faire quelque chose (ET VITE) pour empêcher n’importe qui de devenir mainteneur de paquets orphelins comme ça, sans montrer patte blanche au préalable.
Nous sommes en 2026, pas en 2006, la fréquence et l’ampleur des cyberattaques se sont démultipliées, il faut donc s’adapter et mettre des dispositifs de contrôle là où il n’y en avait pas besoin auparavant.
D’où l’idée abordé sur une des mailing list de laisser un utilisateur patienter une semaine – voire plus – avant d’adopter le moindre paquet.
Le problème est surtout liée au nombre de paquets disponibles. Sans une équipe de 150 ou 200 personnes travaillant en 24/7, on ne résoudra pas le problème lié à ce genre d’attaques.
A titre perso, je pense que la meilleure voie serait que les développeurs de Yay/Paru/Aura forcent l’usage d’un vérificateur de script (PKGbuild) quand on utilise ces wrappers.
On n’arrivera jamais à contrôler totalement les gens qui postent sur AUR (et, à priori, l’un des comptes fautifs était un compte considéré comme fiable).
Reste la solution de faire taffer une IA qui s’amuserait à vérifier les PKGbuild (et, pour avoir testé, elles ne sont jamais satisfaites des PKGbuild et pas une ne donne les mêmes correctifs)
Le noeud du problème, c’est de vérifier chaque PKGBUILD et fichier install qui existe. En tout cas, cela ne concerne – pour le moment et sauf erreur de ma part – que les paquets orphelins. Reste à voir combien de temps cette attaque va durer.
J’ai commencé à nettoyer mes vieux paquets AUR qui ne servent à rien (reliquats Qt5/Plasma5 essentiellement), ça prend un peu de temps mais ça réduira la surface d’attaque potentielle. Je n’ai rien d’exotique, mais on ne sait jamais…