Vous installez des SKILL.md dans Claude ou Codex ? Certains peuvent voler vos clés avant même que vous ne voyiez le danger

Un fichier Markdown peut-il voler une clé SSH ? Pas tout seul. Mais un agent qui lui fait confiance peut exécuter les commandes qu’il contient avant que vous ayez compris ce qu’elles cherchent à atteindre. C’est ce qui transforme certains dossiers de skills en chevaux de Troie : ils ressemblent à de la documentation, promettent une tâche utile, puis obtiennent de Claude, Codex ou d’un autre agent les « mains » qui manquent au texte.

Le risque est facile à sous-estimer. La documentation officielle d’OpenAI sur les skills de ChatGPT et Codex décrit un dossier composé de SKILL.md, mais aussi de scripts exécutables, de références et de ressources facultatives. L’agent peut les lire, lancer un shell, ouvrir le réseau et accéder aux fichiers que votre session lui autorise. La bonne question n’est donc pas « ce Markdown contient-il un virus ? », mais « quelles actions ce dossier peut-il faire exécuter à mon agent ? ».

Ce contre-angle complète directement notre présentation du SKILL.md officiel de Xsolla pour guider Claude, Codex et Copilot dans l’intégration d’un paiement. Un skill maintenu par un fournisseur peut réduire les erreurs. Le même mécanisme, distribué par un inconnu ou compromis lors d’une mise à jour, peut aussi diriger l’agent vers vos secrets.

2 826 skills malveillants et 5 629 essais : ce que l’étude a vraiment mesuré

Une prépublication mise en ligne le 5 août 2026 a étudié la réaction de deux agents de code face à des skills synthétiques et malveillants. Les chercheurs sont partis de 471 commandes Linux issues d’Atomic Red Team. Six modèles ont reformulé chacune d’elles sous la forme d’une compétence apparemment utile, soit 2 826 fichiers répartis entre onze tactiques MITRE ATT&CK.

Les skills ont ensuite été présentés à Gemini CLI et Qwen Code dans un dépôt isolé. Après exclusion de 24 essais vides ou interrompus par l’infrastructure, 5 629 exécutions ont été analysées : 2 816 avec Gemini CLI et 2 813 avec Qwen Code.

Le chiffre demande une précision cruciale. Dans ce protocole, un essai est considéré comme réussi dès que l’agent exécute la commande d’attaque ou manifeste une intention explicite de l’exécuter. Les chercheurs mesurent donc l’exploitabilité de l’agent face à l’instruction, pas la réussite finale d’un vol de données sur Internet. Le sandbox ne pouvait d’ailleurs pas interagir avec un système extérieur.

Autre signal préoccupant : une reconnaissance explicite du danger n’apparaît que dans 1,99 % de l’ensemble des essais. Les tactiques d’accès initial et d’évasion des défenses ont obtenu les taux regroupés les plus élevés, respectivement 91,2 % et 90,4 %. Pour l’exfiltration, le résultat cumulé atteint 67,2 %, avec un écart considérable entre les deux agents.

Le danger n’est plus seulement fabriqué en laboratoire

Le 7 août, TechRadar a relayé une enquête de Zenity Labs sur des skills piégés publiés dans un registre public. Les paquets imitaient des compétences populaires ou utilisaient des noms proches. Certains auraient d’abord paru inoffensifs, avant qu’une mise à jour ne leur ajoute un comportement malveillant : une variante du rug pull appliquée à la chaîne d’approvisionnement logicielle.

Les chercheurs disent avoir observé des tentatives de collecte de clés SSH, identifiants cloud, jetons Git et gestionnaires de paquets, configurations Kubernetes ou Docker, accès aux bases de données, fichiers d’infrastructure et fichiers .env. Les informations étaient regroupées avec des données sur la machine, puis préparées pour l’exfiltration.

Une famille aurait dépassé 1,7 million d’installations agrégées. Ce nombre n’est pas un décompte de victimes uniques. La documentation de skills.sh explique que son classement repose sur une télémétrie d’installation anonyme ; une même personne, une automatisation ou plusieurs réinstallations peuvent donc alimenter le compteur. Zenity n’a pas pu déterminer combien de systèmes avaient réellement été compromis.

Une autre étude empirique portant sur 98 380 skills de deux registres avait déjà confirmé 157 compétences malveillantes et 632 vulnérabilités. Ces nombres restent minoritaires à l’échelle du corpus, mais ils suffisent à invalider l’idée qu’un registre ou une forte popularité constitue un contrôle de sécurité.

Pourquoi SKILL.md possède deux surfaces d’attaque

Un paquet de code classique peut cacher un script nuisible. Un skill ajoute une seconde couche : des instructions en langage naturel conçues précisément pour convaincre un agent d’utiliser ce code. L’OWASP classe ce risque AST01 parmi les menaces critiques pour les skills agentiques.

La couche d’instructions

Le texte peut présenter une lecture de ~/.ssh comme une « vérification de configuration », un envoi réseau comme une « synchronisation » ou la désactivation d’un contrôle comme un « prérequis ». Il peut aussi demander à l’agent de ne pas expliquer une commande, de masquer sa sortie ou de poursuivre sans validation. Le comportement dangereux se cache alors dans le sens de la procédure, pas dans une signature binaire connue.

La couche exécutable

Les skills documentés par Anthropic peuvent embarquer des scripts, des modèles et des exemples à côté de SKILL.md. Un appel vers scripts/validate.sh, npm install ou un outil Python étend l’audit aux fichiers invoqués, à leurs dépendances et aux scripts d’installation. Un fichier de 30 lignes peut ainsi être la façade d’une chaîne beaucoup plus grande.

Ce modèle diffère d’AGENTS.md, qui fixe les règles communes d’un dépôt, mais le principe de confiance est voisin : tout texte interprété comme une autorité par l’agent mérite une revue. Le nom du fichier ne crée pas une frontière de sécurité.

Audit avant installation : inspectez ces six zones

1. Provenance. Vérifiez l’auteur, le dépôt officiel, l’historique, la licence, les mainteneurs et la révision exacte. Préférez un tag ou un commit épinglé à une branche mouvante.
2. Instructions. Lisez le SKILL.md en entier et recherchez les demandes de silence, de contournement des permissions, de téléchargement, d’obfuscation ou d’accès hors du projet.
3. Scripts et références. Suivez chaque chemin mentionné. Ouvrez aussi les fichiers chargés de façon conditionnelle, les modèles, hooks, exemples et binaires fournis.
4. Dépendances. Inspectez package.json, fichiers de verrouillage, scripts preinstall/postinstall, requirements Python, images Docker et téléchargements effectués pendant l’installation.
5. Capacités demandées. Dressez la liste réelle : lecture du dépôt, écriture, shell, réseau, navigateur, variables d’environnement, dossiers personnels, outils cloud, Git et secrets.
6. Mises à jour. Relisez le diff avant chaque nouvelle version. Un paquet audité hier peut changer demain ; la popularité accumulée ne protège pas d’une mise à jour piégée.

Une signature cryptographique reste utile pour vérifier que le paquet vient bien de son éditeur et n’a pas changé en transit. Elle ne répond pas à la question « cet éditeur est-il fiable ? » et ne détecte pas un comportement dangereux volontairement signé.

Un scanner défensif de 10 minutes pour repérer les signaux faibles

Le script Node.js suivant n’exécute aucun fichier du skill. Il parcourt les petits fichiers texte et affiche uniquement le chemin, le numéro de ligne et la catégorie détectée, sans recopier la ligne complète qui pourrait contenir un secret. Enregistrez-le sous audit-skill.mjs, puis lancez-le sur une copie du dossier téléchargé.

import { readdir, readFile, stat } from "node:fs/promises";
import { join, relative } from "node:path";

const root = process.argv[2];
if (!root) throw new Error("Usage: node audit-skill.mjs CHEMIN_DU_SKILL");

const rules = [
  ["réseau", /\b(curl|wget|Invoke-WebRequest|fetch\s*\(|https?:\/\/|nc|socat)\b/i],
  ["secrets", /(process\.env|\.env\b|\.ssh|\.aws|\.kube|\.docker|git-credentials)/i],
  ["exécution", /\b(eval|exec|child_process|subprocess|os\.system|powershell|bash\s+-c)\b/i],
  ["obfuscation", /\b(base64|fromCharCode|decode64|xxd\s+-r)\b/i],
  ["privilèges", /\b(sudo|chmod\s+[47]|chown|Set-ExecutionPolicy)\b/i],
  ["persistance", /(crontab|schtasks|LaunchAgents|systemd|\.bashrc|\.zshrc|hooks?)/i],
  ["installation", /(preinstall|postinstall|pip\s+install|npm\s+install|docker\s+pull)/i],
];

async function walk(dir) {
  for (const entry of await readdir(dir, { withFileTypes: true })) {
    if ([".git", "node_modules", ".venv"].includes(entry.name)) continue;
    const path = join(dir, entry.name);
    if (entry.isDirectory()) await walk(path);
    else if ((await stat(path)).size <= 2_000_000) {
      let text;
      try { text = await readFile(path, "utf8"); } catch { continue; }
      text.split(/\r?\n/).forEach((line, index) => {
        for (const [label, pattern] of rules) {
          if (pattern.test(line)) console.log(`${relative(root, path)}:${index + 1} [${label}]`);
        }
      });
    }
  }
}

await walk(root);

node audit-skill.mjs ./skill-a-verifier

Un résultat n’est pas une preuve de malveillance. Un skill de déploiement peut légitimement utiliser le réseau, Docker ou des variables d’environnement. Le scanner sert à construire la liste des points que vous devez expliquer avant installation. À l’inverse, l’absence d’alerte ne garantit rien : une instruction en langage naturel, un binaire ou une dépendance distante peut contourner ces motifs.

Testez le skill comme un logiciel non fiable

Les auteurs de l’étude recommandent des permissions graduées et une validation explicite pour les opérations sensibles. L’OWASP ajoute l’isolation, l’analyse comportementale, la journalisation structurée et la réputation des sources. En pratique, la première exécution devrait ressembler à ceci :

• un utilisateur système ou un conteneur jetable, sans accès à vos dossiers personnels ;
• une copie du dépôt, montée en lecture seule au départ ;
• aucune véritable clé dans les variables d’environnement, le trousseau ou les fichiers de configuration ;
• un réseau bloqué par défaut, puis limité aux domaines réellement nécessaires ;
• une approbation humaine obligatoire avant le shell, la suppression, l’installation de dépendances, l’accès aux secrets et les modifications hors du projet ;
• des journaux qui conservent les actions et destinations sans enregistrer le contenu des secrets.

Évitez les modes qui désactivent globalement les confirmations. Une permission permanente accordée pour gagner trente secondes rend inutile la validation progressive. La documentation OpenAI sur les approbations et la sécurité de Codex permet justement de distinguer les opérations autorisées dans le sandbox de celles qui doivent être approuvées. Donnez d’abord au skill la capacité minimale nécessaire à sa promesse, puis augmentez-la seulement lorsqu’une étape concrète et comprise l’exige.

Cette isolation devient encore plus importante avec un agent permanent. Dans notre guide d’installation de Hermes Agent sur un serveur dédié avec Plesk, le conteneur, le répertoire de travail et les ressources sont volontairement limités : un skill chargé sur un serveur disponible 24 h/24 ne doit jamais recevoir automatiquement l’ensemble des sites, sauvegardes et clés de la machine.

Que faire si le skill est déjà installé ?

1. Arrêtez l’agent et désactivez le skill pour empêcher une nouvelle activation automatique.
2. Préservez les éléments d’enquête : URL d’origine, version, commit, hash des fichiers, journaux d’actions et destinations réseau. Ne relancez pas le paquet pour « voir ce qu’il fait » sur la machine de production.
3. Reconstituez ses accès réels. Quels dossiers, variables, sockets, outils cloud, navigateurs et identifiants étaient visibles pendant l’exécution ?
4. Inspectez les modifications persistantes : hooks Git, mémoire de l’agent, fichiers d’instructions, tâches planifiées, profils shell, services, extensions et dépendances ajoutées.
5. Remplacez uniquement les secrets potentiellement exposés en vous fondant sur ces accès et les journaux, puis invalidez les sessions concernées. Une rotation ciblée et documentée vaut mieux qu’une panique sans périmètre.
6. Reconstruisez l’environnement jetable depuis une source saine au lieu d’essayer de faire confiance à un nettoyage incomplet.

Si le skill provenait d’un registre, signalez le paquet avec ses indicateurs sans publier de clés, de données personnelles ou de charges réutilisables. La suppression du registre protège les futurs téléchargements, mais elle ne retire pas les copies déjà installées.

La checklist qui doit remplacer le bouton « installer » automatique

• Le besoin justifie-t-il vraiment un nouveau skill ?
• Le dépôt est-il officiel et la révision épinglée ?
• Tous les fichiers, scripts et dépendances ont-ils été lus ou expliqués ?
• Les accès demandés correspondent-ils exactement à la tâche annoncée ?
• Le réseau est-il bloqué ou limité à une liste connue ?
• L’environnement de test contient-il uniquement de faux secrets ?
• Le shell, les suppressions, les secrets et les modifications persistantes exigent-ils une confirmation ?
• La mise à jour suivante sera-t-elle comparée avant exécution ?

Les skills ne sont pas une mauvaise idée. Ils peuvent transmettre à plusieurs agents une méthode maintenue, réduire les erreurs et rendre une intégration reproductible. Mais leur utilité vient précisément du pouvoir qu’ils obtiennent sur le comportement de l’agent. Plus Claude, Codex et leurs concurrents savent agir, moins un fichier d’instructions doit être traité comme une simple documentation.

Article vérifié le 11 août 2026 à partir de la prépublication et de son jeu de données, des documentations OWASP, Anthropic et skills.sh, ainsi que des travaux publics cités. Les registres, paquets et mécanismes de permissions évoluent rapidement : contrôlez toujours la version réellement installée.