AUR compromis : 400 paquets Arch diffusent rootkit et infostealer

Une campagne de compromission a visé l’Arch User Repository (AUR) avec la modification malveillante de plus de 400 paquets, selon les éléments relayés par The Hacker News à partir d’analyses publiques de sécurité. Le point critique n’est pas une vulnérabilité logicielle classique avec correctif unique et identifiant CVE, mais un incident de chaîne d’approvisionnement logicielle : des paquets AUR ont été altérés pour exécuter des scripts malveillants lors de l’installation. L’impact rapporté inclut le vol d’identifiants et de secrets, ainsi qu’une persistance avancée via un rootkit eBPF sur des systèmes Linux.

Mise à jour du 29/06/2026 — Le 15 juin 2026, Arch Linux a confirmé un « active AUR malicious packages incident » et a indiqué avoir temporairement restreint les nouvelles inscriptions sur l’AUR pour freiner la vague d’adoptions et de mises à jour malveillantes. Des suivis publiés ensuite ont fait état d’une extension de la campagne au-delà des 400 paquets initialement signalés. (archlinux.org)

Mise à jour du 01/07/2026 — L’incident a bien évolué au-delà du seuil initial : Arch Linux a confirmé une « active AUR malicious packages incident » le 12 juin 2026, et des sources concordantes indiquent que la campagne dite « Atomic Arch » a dépassé les 400 paquets compromis, avec des estimations montées à plus de 1 500 paquets affectés dans l’AUR. (archlinux.org) Les paquets malveillants restaient dans l’AUR communautaire — et non dans les dépôts officiels d’Arch Linux — et ajoutaient un script installant `atomic-lockfile`, utilisé pour déployer un infostealer Linux avec capacités de rootkit eBPF. (bleepingcomputer.com)

Mise à jour du 02/07/2026 — L’incident a bien été confirmé par Arch Linux le 12 juin 2026, qui a annoncé une « active AUR malicious packages incident » et a temporairement restreint certaines actions sur l’AUR pendant le nettoyage. (archlinux.org) Des sources concordantes indiquent ensuite que l’attaque initialement signalée sur plus de 400 paquets a évolué en une campagne plus large, certains suivis parlant d’environ 1 500 paquets AUR compromis au total. (bleepingcomputer.com)

Mise à jour du 30/06/2026 — Selon les informations publiées le 12 juin 2026, l’incident a bien été confirmé : plus de 400 paquets de l’AUR ont été compromis pour diffuser un infostealer Linux et, avec les privilèges root, un rootkit eBPF. (bleepingcomputer.com) Des sources ultérieures indiquent en outre que le périmètre a ensuite été réévalué à plus de 1 500 paquets compromis, ce qui constitue une évolution récente vérifiée sur ce même incident. (linuxtricks.fr)

Pour les équipes d’exploitation, DevOps, SRE et développement, l’enjeu est immédiat : tout hôte ayant installé ou mis à jour un paquet AUR compromis doit être considéré comme potentiellement exposé. Contrairement à un dépôt officiel signé de bout en bout, l’AUR repose sur des recettes communautaires, notamment des fichiers PKGBUILD, qui décrivent comment récupérer, construire et empaqueter un logiciel. Si ces recettes sont modifiées à des fins malveillantes, le poste d’administration, le serveur de build, le runner CI ou la machine de développement peut exécuter du code hostile avec les privilèges de l’utilisateur qui lance la construction, voire plus selon les pratiques locales.

À ce stade, il ne s’agit pas d’une faille publiée avec CVE-ID ou score CVSS unique dans la source citée, mais d’un incident supply chain documenté publiquement. La source initiale mentionnée ici est l’article de The Hacker News, Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit. En l’absence d’un avis éditeur centralisé présentant une matrice de versions vulnérables et corrigées au sens habituel d’un logiciel, la réponse doit se concentrer sur l’identification des paquets AUR installés, la suppression des paquets compromis, la rotation des secrets et, selon le niveau d’exposition, la réinstallation depuis des sources vérifiées.

Pour des infrastructures hébergées chez OVHcloud, Scaleway, o2switch ou sur des VPS Linux autogérés, le risque est particulièrement concret si des automatisations internes utilisent l’AUR dans des images de build, des bastions ou des serveurs d’administration. Le point d’attention principal est simple : un PKGBUILD n’est pas un simple manifeste passif, c’est une recette shell capable d’exécuter des actions pendant la récupération, la préparation, la compilation et l’empaquetage.

Versions affectées

Il n’existe pas, dans la source citée, de liste de versions vulnérables et corrigées comparable à celle d’un advisory CVE classique. Le périmètre affecté doit donc être défini autrement :

• Sont potentiellement affectés les systèmes Arch Linux ou dérivés ayant installé, construit ou mis à jour des paquets AUR faisant partie des paquets compromis signalés publiquement.
• Sont particulièrement exposés les hôtes utilisant des assistants AUR ou des workflows automatisés qui récupèrent et exécutent des PKGBUILD sans revue humaine suffisante.
• Ne sont pas concernés au même titre les paquets des dépôts officiels Arch lorsqu’ils n’ont pas de dépendance ou d’étape de build transitant par l’AUR compromis.

En pratique, la notion de “version affectée” correspond ici à tout état du paquet AUR compromis tel qu’il a été publié pendant la fenêtre de compromission. Si un système a récupéré le PKGBUILD malveillant ou exécuté une mise à jour issue de cette recette, il faut le traiter comme suspect.

Faute de matrice officielle unique dans la source mentionnée, la démarche recommandée est la suivante :

• identifier les paquets AUR présents sur les hôtes concernés ;
• comparer les recettes locales, caches et historiques avec les informations publiées par la communauté Arch et les mainteneurs légitimes ;
• supprimer les paquets compromis ;
• réinstaller uniquement depuis des sources vérifiées après validation du contenu du PKGBUILD et de ses sources amont.

Pour inventorier les paquets installés qui ne proviennent pas des dépôts officiels synchronisés, une première base de travail consiste à lister les paquets “foreign” :

pacman -Qm

Cette commande n’identifie pas à elle seule les paquets compromis, mais elle permet de circonscrire le périmètre d’analyse. Sur un poste d’administration ou un runner CI, cette liste doit être rapprochée des journaux d’installation, des caches d’assistants AUR et des commits des recettes utilisées au moment des builds.

Si l’environnement utilise un assistant AUR, il faut aussi examiner son cache local. Le chemin exact dépend de l’outil utilisé, mais l’objectif est constant : retrouver le contenu du PKGBUILD réellement exécuté. Sur des machines de build éphémères, cette étape peut être impossible après coup ; dans ce cas, l’absence de preuve saine doit être interprétée avec prudence.

Vecteur d’attaque

Le vecteur d’attaque est celui d’une compromission de chaîne d’approvisionnement via l’AUR. Techniquement, l’attaque exploite le fait que les paquets AUR sont définis par des recettes, généralement un fichier PKGBUILD et parfois des fichiers annexes, qui sont récupérés puis exécutés localement pour construire le paquet. Si un attaquant parvient à modifier ces recettes, il peut injecter des commandes shell ou des étapes de récupération de charge utile malveillante.

Le point essentiel pour les équipes Linux est que l’exécution ne dépend pas d’un binaire précompilé opaque : elle peut survenir pendant le processus de build, via des fonctions telles que prepare(), build(), check() ou package(), ou encore par des commandes shell placées dans le flux principal du fichier. Une revue insuffisante du PKGBUILD ou une automatisation trop permissive transforme alors un simple mécanisme d’installation communautaire en vecteur d’exécution de code arbitraire.

Un exemple minimal de structure légitime d’un PKGBUILD ressemble à ceci :

pkgname=exemple
pkgver=1.0.0
pkgrel=1
arch=('x86_64')
source=("https://source.example.org/projet-${pkgver}.tar.gz")
sha256sums=('...')

build() {
  cd "${srcdir}/projet-${pkgver}"
  make
}

package() {
  cd "${srcdir}/projet-${pkgver}"
  install -Dm755 binaire "${pkgdir}/usr/bin/exemple"
}

Dans un scénario de compromission supply chain, l’attaquant n’a pas besoin de modifier radicalement la structure. Quelques lignes suffisent pour détourner le flux, par exemple via l’ajout d’un téléchargement externe, d’une exécution de script, d’une collecte de variables d’environnement ou d’un accès à des fichiers sensibles. Le risque n’est pas théorique : les informations relayées publiquement font état de scripts malveillants conçus pour déployer un infostealer et un rootkit eBPF.

L’impact opérationnel dépend fortement du contexte d’exécution :

• sur un poste développeur, le code malveillant peut viser les clés SSH, tokens Git, identifiants de registres de conteneurs, sessions cloud, historiques shell et secrets stockés localement ;
• sur un runner CI/CD, il peut exposer des variables d’environnement, des jetons d’accès aux dépôts, des secrets de déploiement, des identifiants vers des registries ou des comptes cloud ;
• sur un serveur d’administration, il peut compromettre des coffres de secrets, des accès SSH privilégiés, des tunnels, des scripts d’automatisation et des comptes de service ;
• sur un serveur applicatif, il peut ouvrir la voie à une persistance locale, à l’exfiltration de configuration ou à un mouvement latéral vers d’autres hôtes.

La mention d’un rootkit eBPF est particulièrement importante. eBPF permet d’exécuter des programmes dans le noyau Linux sous des contraintes spécifiques. Utilisé légitimement, il sert à l’observabilité, au réseau et à la sécurité. Détourné, il peut offrir des capacités de furtivité, d’interception ou de persistance avancée. Le simple fait qu’une telle charge soit évoquée doit faire monter le niveau de réponse : un nettoyage superficiel du paquet installé n’est pas suffisant si l’hôte a effectivement exécuté le code malveillant.

Sur le plan de l’attaque, la séquence typique est la suivante :

• l’utilisateur ou l’automate récupère un paquet AUR compromis ;
• le PKGBUILD ou un script associé exécute des commandes malveillantes pendant la phase de build ou d’installation ;
• des secrets locaux sont collectés et exfiltrés ;
• une charge de persistance peut être installée, dont un composant eBPF selon les rapports publics ;
• les accès volés sont réutilisés pour rebondir vers d’autres systèmes, dépôts, registres ou comptes cloud.

Il faut aussi noter un risque souvent sous-estimé : la contamination des pipelines. Une machine de build compromise peut produire des artefacts applicatifs apparemment sains mais construits dans un environnement non fiable. Cela impose parfois de reconstruire les images, paquets et binaires à partir d’une chaîne de confiance réinitialisée.

Impact

L’impact principal documenté dans la source relayée est double : vol d’informations sensibles et persistance sur Linux. Dans un environnement moderne, cela dépasse largement le périmètre du poste local.

Vol de secrets et d’identifiants

Un infostealer sur une machine d’administration ou de développement peut viser :

• les clés privées dans ~/.ssh/ ;
• les fichiers de configuration Git et les credentials helpers ;
• les tokens de plateformes de forge logicielle ;
• les identifiants de registres de conteneurs ;
• les variables d’environnement exportées dans les shells ou injectées par la CI ;
• les fichiers de configuration cloud tels que ~/.aws/, ~/.config/gcloud/ ou équivalents ;
• les historiques shell, notamment ~/.bash_history et ~/.zsh_history, qui contiennent parfois des commandes avec secrets ;
• les fichiers applicatifs comme .env, config.yml, credentials.json ou des variables présentes dans des scripts de déploiement.

Dans beaucoup d’organisations, ces éléments suffisent à compromettre des environnements entiers sans exploiter la moindre faille réseau supplémentaire. Le danger réel n’est donc pas seulement la machine touchée, mais le graphe de confiance auquel elle donne accès.

Persistance et furtivité

La persistance via un rootkit eBPF change la nature de la remédiation. Une fois un composant de bas niveau chargé, la suppression du paquet AUR initial ne garantit pas à elle seule le retour à un état sain. Selon les privilèges obtenus et la configuration du noyau, l’attaquant peut chercher à masquer certaines activités, à intercepter des événements ou à maintenir une présence durable. Dans ce contexte, les réponses purement applicatives sont insuffisantes.

Compromission des pipelines et des artefacts

Si un runner CI, une image de build ou un conteneur de packaging a exécuté un paquet AUR compromis, plusieurs questions se posent :

• des secrets de déploiement ont-ils été exposés ;
• des dépôts Git ont-ils été modifiés via des identifiants volés ;
• des artefacts produits pendant la période de compromission doivent-ils être considérés comme non fiables ;
• des images conteneurs ont-elles embarqué des outils, scripts ou dépendances modifiés ;
• des runners auto-hébergés ont-ils servi de point d’entrée vers le SI interne.

Pour les RSSI et responsables de production, cela implique une réponse orientée incident de confiance, pas seulement un “désinstaller et mettre à jour”.

Comment patcher

Il n’existe pas ici de correctif unique sous la forme d’un paquet système à mettre à jour avec un numéro de version cible. La remédiation consiste à retirer les paquets AUR compromis, à réinstaller depuis des sources vérifiées et à traiter l’hôte comme potentiellement compromis si le code malveillant a pu s’exécuter.

1. Identifier les paquets AUR installés

pacman -Qm

Cette commande liste les paquets installés qui ne proviennent pas des dépôts synchronisés officiels. Sur un parc, elle peut être exécutée via votre outil d’inventaire ou de gestion de configuration pour établir un périmètre initial.

2. Supprimer les paquets suspects ou compromis

La suppression exacte dépend des paquets identifiés. Avec pacman, la commande de base est :

sudo pacman -Rns nom-du-paquet

Si plusieurs paquets sont concernés :

sudo pacman -Rns paquet1 paquet2 paquet3

Cette étape retire le paquet installé et ses dépendances devenues inutiles, mais elle ne constitue pas à elle seule une garantie de nettoyage si des scripts malveillants ont déjà tourné.

3. Purger les caches de build et les répertoires de travail

Les assistants AUR conservent souvent les recettes et répertoires de compilation dans le répertoire utilisateur. Le chemin dépend de l’outil, mais il faut supprimer les copies locales des recettes compromises et reconstruire dans un environnement propre. À défaut de certitude sur le cache, la mesure conservatrice consiste à purger les répertoires de build AUR de l’utilisateur concerné.

Exemple générique de vérification des répertoires cachés liés à l’AUR :

find "$HOME" -maxdepth 3 -type f \( -name PKGBUILD -o -name .SRCINFO \)

Cette commande aide à localiser les recettes présentes localement pour inspection ou suppression. Elle ne remplace pas une analyse forensique, mais elle permet de retrouver rapidement des traces de build.

4. Réinstaller uniquement depuis des sources vérifiées

Si le logiciel reste nécessaire, il faut repartir d’une recette saine, idéalement validée par le mainteneur légitime et comparée à la source amont. La bonne pratique est de lire le PKGBUILD avant exécution, de vérifier les URL de source, les sommes de contrôle et l’absence de commandes inattendues.

Un contrôle minimal consiste à ouvrir le fichier :

less PKGBUILD

et à rechercher des éléments suspects :

grep -nE 'curl|wget|bash|sh |nc |python|perl|openssl s_client|/dev/tcp|systemctl|modprobe|bpftool' PKGBUILD

Cette recherche n’est pas une preuve de malveillance, car certaines commandes peuvent être légitimes, mais elle aide à repérer les recettes nécessitant une revue approfondie.

5. Rotation des secrets exposés

Toute machine ayant exécuté un paquet compromis doit déclencher une rotation des secrets. Cela inclut au minimum :

• clés SSH utilisateurs et comptes de service ;
• tokens Git et accès API ;
• mots de passe de registries et dépôts ;
• credentials cloud ;
• secrets CI/CD ;
• jetons d’accès aux gestionnaires de secrets.

Il n’existe pas de commande universelle pour cette étape, car elle dépend des plateformes utilisées. En revanche, l’ordre des priorités est clair : révoquer avant de réutiliser.

6. Réinstaller l’hôte si une exécution malveillante est probable

En présence d’un soupçon crédible de persistance, notamment avec une charge eBPF, la réponse la plus sûre est une réinstallation complète depuis une image de confiance. Pour un serveur, cela signifie généralement :

• provisionner une nouvelle instance à partir d’une image saine ;
• réappliquer la configuration via Infrastructure as Code ;
• restaurer uniquement des données vérifiées ;
• réinjecter des secrets nouvellement générés ;
• retirer l’ancienne machine du réseau puis la conserver pour analyse si nécessaire.

Sur Arch Linux, la mise à jour générale du système reste une mesure d’hygiène utile mais ne corrige pas l’incident supply chain à elle seule :

sudo pacman -Syu

Elle permet de s’assurer que le socle système est à jour, mais la priorité reste la suppression des paquets compromis, la rotation des secrets et la reconstruction de la confiance.

Détection

La détection doit combiner inventaire, analyse des journaux, recherche de traces locales et surveillance réseau. Comme il ne s’agit pas d’une vulnérabilité à signature unique, l’objectif est de repérer des indicateurs de construction ou d’exécution anormaux autour des paquets AUR.

Inventaire et historique local

Commencez par identifier les paquets AUR présents et l’historique de leur installation. Sur Arch, les journaux pacman sont une source utile :

grep -E 'installed|upgraded|removed' /var/log/pacman.log

Pour cibler un paquet précis :

grep 'nom-du-paquet' /var/log/pacman.log

Ces traces permettent de dater les installations et mises à jour, ce qui aide à croiser avec la fenêtre de compromission connue publiquement.

Recherche de traces de build AUR

Les recettes AUR et fichiers temporaires peuvent laisser des indices dans les répertoires utilisateurs :

find /home -type f \( -name PKGBUILD -o -name .SRCINFO -o -name '*.install' \) 2>/dev/null

Inspectez ensuite les contenus suspects, notamment les téléchargements externes, les commandes shell inhabituelles et les modifications récentes.

Recherche de secrets potentiellement exposés

La recherche de fichiers sensibles sur les hôtes touchés aide à prioriser la rotation des secrets :

find "$HOME" -maxdepth 3 \( -path '*/.ssh/*' -o -path '*/.aws/*' -o -path '*/.config/gcloud/*' -o -name '.env' -o -name 'credentials*' \) 2>/dev/null

Le but n’est pas de confirmer l’exfiltration, ce qui est souvent impossible a posteriori, mais de dresser la liste des secrets qui auraient pu être lus.

Surveillance des programmes eBPF

Si l’environnement permet l’usage de bpftool, il peut être pertinent d’inspecter les programmes et maps chargés. La sortie doit être interprétée par un administrateur Linux expérimenté, car de nombreux composants légitimes utilisent eBPF :

sudo bpftool prog show

sudo bpftool map show

La présence d’objets inattendus, surtout sur des hôtes qui n’utilisent normalement pas eBPF pour l’observabilité ou le réseau, doit déclencher une investigation plus poussée. Cela ne constitue pas un IoC définitif, mais un signal de suspicion pertinent dans le contexte de cet incident.

Services, persistance et modifications système

Il faut également vérifier les mécanismes de persistance classiques :

• unités systemd ajoutées ou modifiées ;
• tâches planifiées ;
• scripts dans /etc/profile.d/ ;
• ajouts dans ~/.bashrc, ~/.zshrc, ~/.profile ;
• binaires inconnus dans /usr/local/bin/, /tmp/, /var/tmp/ ou le répertoire utilisateur.

Quelques commandes de triage utiles :

systemctl list-unit-files --state=enabled

crontab -l

sudo ls -al /etc/cron.* /etc/systemd/system /usr/local/bin /tmp /var/tmp

Là encore, il ne s’agit pas d’IoC exclusifs à cet incident, mais de points de contrôle réalistes pour repérer une persistance opportuniste.

Réseau et exfiltration

Une machine ayant exécuté un script malveillant peut avoir établi des connexions sortantes inhabituelles. Selon les outils disponibles, examinez :

• les journaux de pare-feu hôte ;
• les logs proxy ou DNS ;
• les flux sortants observés par l’EDR ou la supervision réseau ;
• les connexions vers des domaines ou adresses IP non habituellement contactés par les postes de build.

Comme la source citée ne fournit pas ici une liste consolidée d’IoC réseau à reprendre textuellement, il est préférable de ne pas inventer de domaines, d’IP ou de hachages. En revanche, toute connexion sortante apparue au moment d’une construction AUR vers une destination non attendue mérite une investigation.

Mitigation

Si le patch complet n’est pas immédiatement possible, plusieurs mesures de réduction du risque peuvent être mises en place sans attendre.

Interdire l’AUR sur les systèmes sensibles

Les serveurs de production, bastions, runners CI critiques et images de base ne devraient pas dépendre directement de paquets AUR sauf nécessité strictement encadrée. Sur ces hôtes, la mitigation la plus robuste est organisationnelle : pas d’AUR en production, ou seulement via un processus de revue et de mirroring interne.

Revue systématique des PKGBUILD

Un PKGBUILD doit être traité comme du code exécutable. Avant toute installation :

• vérifier les URL de source ;
• contrôler les sommes de contrôle ;
• inspecter les fonctions prepare(), build(), check() et package() ;
• se méfier des téléchargements additionnels non documentés ;
• refuser les recettes qui invoquent des scripts distants ou des commandes shell opaques.

Cette discipline est essentielle dans les équipes qui utilisent des assistants AUR pour gagner du temps. L’automatisation ne doit pas supprimer la revue de code quand la chaîne d’approvisionnement repose sur des recettes shell communautaires.

Isoler les builds

Construire les paquets AUR dans des environnements éphémères, isolés et sans secrets réduit fortement l’impact d’un paquet malveillant. Concrètement :

• utiliser des VM ou conteneurs jetables pour le build ;
• ne pas monter les répertoires personnels contenant clés et tokens ;
• ne pas injecter de secrets de production dans l’environnement de compilation ;
• restreindre le réseau sortant au strict nécessaire ;
• promouvoir ensuite uniquement les artefacts validés vers les environnements internes.

Cette approche est particulièrement pertinente pour les équipes qui opèrent sur des infrastructures cloud chez OVHcloud ou Scaleway, où la création d’environnements éphémères et cloisonnés peut être automatisée.

Réduire l’exposition des secrets

Un poste de build ne devrait pas détenir plus de secrets que nécessaire. Quelques mesures efficaces :

• utiliser des jetons à durée de vie courte ;
• segmenter les comptes de service par usage ;
• préférer des identités fédérées ou des accès temporaires ;
• éviter le stockage de secrets en clair dans les fichiers shell ou les historiques ;
• désactiver l’accès direct aux environnements sensibles depuis les postes de développement.

Journaliser et alerter sur les builds communautaires

Si l’usage de l’AUR est autorisé, il doit être visible. Il est pertinent de journaliser :

• les paquets AUR installés ;
• les commits ou snapshots des recettes utilisées ;
• les hôtes et utilisateurs ayant lancé les builds ;
• les connexions sortantes pendant la construction ;
• les artefacts produits et leur destination.

Cette traçabilité simplifie énormément la réponse à incident lorsque survient une compromission de chaîne d’approvisionnement.

Perspective écosystème et points de vigilance

Cet incident rappelle une réalité parfois mal comprise : la confiance dans un écosystème de paquets communautaires n’est pas équivalente à celle d’un dépôt officiel entièrement maîtrisé. L’AUR est un outil précieux pour la communauté Arch, mais son modèle suppose une vigilance active des utilisateurs et des administrateurs. Un PKGBUILD n’est pas un simple descripteur ; c’est un script de construction qui mérite une revue de sécurité, surtout lorsqu’il est utilisé dans des contextes à privilèges ou dans des pipelines.

Pour les organisations, la leçon dépasse Arch Linux. Le même schéma existe ailleurs sous des formes différentes : scripts d’installation, hooks de build, dépendances transitives, paquets communautaires, images de base non vérifiées, actions CI tierces. Le point commun est toujours le même : une dépendance ou une recette de build peut devenir un point d’exécution de code hostile si la chaîne de confiance n’est pas explicitement contrôlée.

Les équipes sécurité peuvent utilement rapprocher cet incident des recommandations générales de CERT-FR sur la gestion des compromissions, la rotation des secrets et le durcissement des environnements d’administration. Même sans bulletin CERT-FR spécifique cité ici pour ce cas précis, le cadre méthodologique reste applicable : qualification du périmètre, confinement, éradication, reconstruction de la confiance, surveillance renforcée et retour d’expérience.

Pour les structures qui hébergent elles-mêmes leurs runners, registries ou bastions chez des prestataires français comme OVHcloud, Scaleway ou o2switch, la priorité est de vérifier si des images internes, scripts d’installation ou procédures d’administration intègrent l’AUR de façon non maîtrisée. Ce type d’usage est fréquent dans les petites équipes et les environnements de prototypage, puis persiste parfois en production sans revue formelle.

En pratique, si un hôte a installé un paquet AUR compromis, la bonne question n’est pas seulement “quel paquet supprimer ?”, mais aussi “quels secrets cet hôte pouvait-il atteindre ?”, “quels artefacts a-t-il produits ?” et “sur quels autres systèmes ses accès permettaient-ils de rebondir ?”. C’est cette lecture orientée chaîne d’approvisionnement qui permet d’éviter une remédiation incomplète.

À court terme, la réponse la plus sûre reste de supprimer les paquets compromis, révoquer les secrets potentiellement exposés et reconstruire les hôtes ou pipelines sensibles depuis des sources vérifiées. À moyen terme, il faut encadrer l’usage de l’AUR, isoler les builds et traiter chaque PKGBUILD comme du code tiers à auditer. Pour renforcer durablement ce type de posture, un passage par les bonnes pratiques de durcissement et de gestion des secrets reste indispensable sur /categorie/pratiques.