BRIEFING SÉCURITÉ · 12.08.2026 DEENFRES

Actualités

400 paquets AUR contenant des logiciels malveillants: ce que nous apprend l’attaque contre Arch Linux

Par Alec Chizhik · 13 juin 2026 · 7 min de lecture

Plus de 400 paquets dans l’Arch User Repository contenaient du code malveillant à la mi-juin 2026. Des attaquants ont pris le contrôle de projets abandonnés, ont intégré un infostealer et un rootkit eBPF dans les scripts de build, et ont attendu que les utilisateurs les installent. L’affaire touche formellement Arch Linux. Le schéma sous-jacent concerne toute organisation qui se procure des logiciels à partir de dépôts de paquets ouverts.

Les points clés en bref

  • Des paquets abandonnés comme porte d’entrée : Les attaquants ont adopté des paquets AUR sans propriétaire via le processus de reprise standard et en ont modifié les scripts de build. Selon les rapports, plus de 400 paquets ont été touchés.
  • Des dégâts en deux étapes : Les scripts téléchargeaient des paquets en aval qui exécutaient un infostealer écrit en Rust. Avec les droits root, le logiciel malveillant chargeait en outre un rootkit eBPF pour se dissimuler.
  • Le risque est transposable : Le même schéma s’applique à npm, PyPI et à d’autres sources ouvertes. Quiconque intègre des dépendances non vérifiées dans son pipeline présente la même faille, et ce, sans même utiliser Arch Linux.

Articles connexes :Sécurité des API : l’angle mort derrière chaque intégration  /  Le noyau partagé comme faille

Ce qui s’est passé dans l’Arch User Repository

Qu’est-ce qu’une attaque de la supply chain logicielle ? Lors d’une attaque de la supply chain, un attaquant ne manipule pas directement le système cible, mais un composant auquel la cible fait confiance : une bibliothèque, un paquet, un script de build. Le logiciel malveillant arrive par la voie classique de mise à jour ou d’installation, contournant ainsi les mesures de défense qui ne vérifient que les accès directs.

L’Arch User Repository, ou AUR, est une collection de recettes de compilation maintenue par la communauté, et non le dépôt officiel d’Arch. Les utilisateurs téléchargent des scripts dits PKGBUILD, que des assistants comme yay ou paru exécutent lors de l’installation. Ce sont précisément ces scripts qui ont été ciblés.

Selon les rapports de médias spécialisés en cybersécurité comme BleepingComputer et The Hacker News, les attaquants ont recherché des paquets abandonnés, c’est-à-dire des projets sans responsable actif, et les ont repris via le processus d’adoption standard de l’AUR. Ils ont ensuite modifié les scripts de build de manière à ce que des paquets malveillants en aval soient téléchargés lors de l’installation. Ceux-ci exécutaient un infostealer écrit en Rust, qui dérobait les secrets des développeurs. Si le processus s’exécutait avec les droits root, le logiciel malveillant chargeait en outre un rootkit eBPF pour dissimuler ses traces dans le système. D’après les rapports, les mainteneurs d’Arch Linux ont commencé, dès la découverte de l’affaire, à réinitialiser les paquets concernés et à bloquer les comptes responsables.

Pourquoi ce schéma touche toutes les chaînes d’approvisionnement

Il y a là peu de choses spécifiques à Arch. Le risque réside dans le principe même des dépôts de paquets ouverts. Un paquet abandonné que quelqu’un reprend existe dans npm, PyPI, Crates et tout autre écosystème ouvert. La reprise d’un projet délaissé est un mécanisme prévu dans bon nombre de ces sources, qui peut être retourné contre la communauté.

Pour une entreprise DACH, cela signifie que : chaque dépendance qu’un développeur ou un pipeline intègre sans vérification constitue un point d’entrée potentiel. Les dégâts ne se limitent alors pas à une installation Linux privée. Ils atteignent les serveurs de build, les machines des développeurs et, dans le pire des cas, la production. Un infostealer intercepte précisément les identifiants qui permettent d’ouvrir l’accès à d’autres systèmes.

Ce que les équipes de sécurité devraient concrètement vérifier dès maintenant

Les contre-mesures sont connues et ne nécessitent aucun outil spécialisé. Elles exigent avant tout de la discipline dans le pipeline.

Ce qui protège

  • Épingler les dépendances à des versions fixes
  • Vérifier les nouveaux paquets ou ceux récemment repris
  • Exécuter les builds sans droits root et en isolation
  • Exclure les secrets des environnements de build

Ce qui est trompeur

  • Se fier uniquement au nom du paquet
  • Mises à jour automatiques sans vérification
  • Traiter les scripts de build comme des boîtes noires
  • Supposer qu’un paquet connu reste sûr

S’ajoute à cela le volet organisationnel. Quiconque tient à jour une nomenclature de ses logiciels, appelée Software Bill of Materials, peut répondre en quelques minutes après un incident si un composant compromis figure dans son propre inventaire. C’est d’ailleurs précisément l’objet de la directive NIS2 : elle exige des entités concernées qu’elles gèrent activement les risques de la chaîne d’approvisionnement, et non pas seulement après un incident.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Les paquets officiels d’Arch Linux sont-ils également concernés ?

Selon les rapports disponibles, l’attaque a ciblé l’Arch User Repository, une collection de scripts de build maintenue par la communauté, et non les dépôts officiels d’Arch Linux. Les paquets AUR sont construits localement à partir de scripts PKGBUILD, ce qui les rend vulnérables à ce type de manipulation.

Combien de paquets ont été touchés et quand ?

Selon des rapports concordants, plus de 400 paquets ont été compromis et l’incident a été révélé aux alentours du 11 juin 2026. Les mainteneurs d’Arch Linux ont commencé à retirer les paquets malveillants et à bloquer les comptes responsables.

Qu’a fait concrètement le logiciel malveillant ?

Les scripts de build manipulés téléchargeaient des paquets en aval qui exécutaient un infostealer écrit en Rust. Celui-ci interceptait les secrets des développeurs. Avec les droits root, le logiciel malveillant téléchargeait en outre un rootkit eBPF pour se dissimuler dans le système.

Cela concerne-t-il également les entreprises qui n’utilisent pas Arch Linux ?

Oui, ce schéma est transposable. Des paquets abandonnés ou repris existent également sur npm, PyPI et autres sources ouvertes. Tout pipeline qui récupère des dépendances sans vérification porte le même risque, indépendamment du système d’exploitation.

Quelle mesure offre la protection la plus rapide ?

Épingler les dépendances à des versions fixes et vérifiées, et exécuter les builds en isolation et sans droits root. Ces deux mesures empêchent qu’un paquet discrètement substitué ne pénètre automatiquement et avec des privilèges élevés dans votre propre système.

Les choix de la rédaction

À lirePriorisation des correctifs : Pourquoi CVSS seul freine votre SOCÀ lireNIS2 et divulgation coordonnée : sortir de la zone griseÀ lireLorsque le serveur de sauvegarde devient lui-même une faille de sécurité

Plus du réseau MBF Media

cloudmagazinKubernetes en tant que système d’exploitation par défaut pour l’IA: les clusters comme question de conformitéDigital ChiefsDu passage du pilote de l’IA au fonctionnement régulier : pourquoi la majorité échoueMyBusinessFuture54,5 % des utilisateurs ont recours à l’IA – et pourtant, les PME restent à la traîne

Pour aller plus loin

Un magazine d'Evernine Media GmbH