Après l'exécution de 1 672 skills Claude, le vrai risque n'est pas le malware

En matière d'outils de développement comme les skills Claude, la crainte en matière de sécurité se traduit par la recherche de malwares classiques : voleurs d'identifiants cachés, commandes shell obfusquées et autres charges utiles dissimulées. Cette crainte est fondée. L'audit ToxicSkills de Snyk a analysé 3 984 skills de ClawHub et skills.sh au 5 février 2026 et a trouvé des modèles d'injection de prompt dans 36 % de l'écosystème, 534 skills avec des problèmes de sécurité critiques, et 76 charges utiles malveillantes confirmées par une revue humaine, dont 8 étaient encore actives sur clawhub.ai au moment de la publication. L'incident parallèle ClawHavoc a vu 341 skills malveillantes retirées du registre de ClawHub. Les skills d'agent malveillantes ne sont pas hypothétiques.

Il est donc important d'être précis sur ce que nous avons trouvé, et sur ce que nos chiffres signifient et ne signifient pas. Chez SkillProof, nous installons et exécutons chaque skill que nous répertorions, puis nous publions le résultat, qu'il soit positif ou négatif. À ce jour, nous avons testé 1 672 skills : 1045 réussissent le test (un taux de réussite de 63 %), 560 nécessitent une configuration manuelle, et 67 ont obtenu un score inférieur à celui de Claude sans aucune skill installée. À notre connaissance, aucun autre répertoire ne publie ses résultats d'échec à côté de ses succès.

Sur ces 1 672 tests exécutés, nous n'avons trouvé aucune instance de malware dissimulé. Ce résultat doit être nuancé : notre catalogue n'est pas un échantillon aléatoire d'un registre public. Les candidats sont pré-filtrés pour leur qualité avant même d'atteindre une phase de test, les dépôts de faible qualité et de spam sont maintenus sur une liste de blocage, et les skills qui parviennent à un verdict publié sont celles qui sont déjà susceptibles d'être légitimes. Snyk a échantillonné le registre ; nous échantillonnons la partie qui mérite d'être installée. Les deux chiffres sont vrais, et ils répondent à des questions différentes.

Ce que notre échantillon permet d'analyser, c'est la question à laquelle personne d'autre ne répond : une fois les malwares évidents filtrés, de quoi faut-il encore s'inquiéter ? La réponse, de manière reproductible, est le périmètre d'explosion des permissions et des capacités des skills légitimes et utiles. Ce risque est plus difficile à détecter par scan, car il réside principalement dans ce qu'une skill vous demande d'approuver à l'installation et à l'exécution.

Ce que nous n'avons pas trouvé : l'absence de charges utiles dissimulées

Soyons directs. En plus de seize cents exécutions de skills uniques, nous avons trouvé :

• Zéro instance d'exfiltration dissimulée d'identifiants vers un serveur inconnu.
• Zéro instance de charge utile curl | sh cachée dans les fichiers propres d'une skill. Plusieurs skills fournissent un installateur curl | bash dans le README de leur dépôt, et dans un cas, l'installation du CLI tiers n'est jamais mentionnée dans le SKILL.md. Il s'agit d'étapes d'installation divulguées que vous pouvez lire avant l'exécution, et non de charges utiles dissimulées, mais elles méritent d'être notées.
• Zéro instance de charges utiles obfusquées en base64 ou d'autres techniques d'obfuscation classiques conçues pour masquer une intention.
• Zéro instruction cachée dans un fichier SKILL.md qui différait de l'objectif public de la skill.

La recherche d'exemples concrets de malwares dans notre ensemble de tests s'est révélée vaine. Cela ne signifie pas que l'analyse est inutile. Cela signifie que les scanners que la plupart des gens utilisent sont réglés sur les mauvaises signatures. Un outil recherchant des modèles de code malveillant ne renvoie rien sur notre échantillon ; un outil réglé sur les modèles de permissions et de capacités détecterait la plupart de ce que nous avons enregistré, car ces modèles sont présents en clair dans le texte des fichiers. La différence réside dans ce que vous recherchez, pas dans l'efficacité de la recherche elle-même. L'exécution permet toujours de détecter ce qu'aucune des deux approches ne trouve : quelles permissions une skill demande réellement lorsque vous l'exécutez, et ce qu'elle écrit dans votre configuration une fois que vous avez donné votre accord. Pour un aperçu plus approfondi de notre processus, consultez comment nous testons les skills Claude.

La menace réelle : le périmètre d'explosion des permissions dans les skills légitimes

Les problèmes de sécurité les plus importants que nous avons trouvés concernaient des skills qui sont par ailleurs fonctionnelles et utiles. Deux des cinq skills ci-dessous réussissent nos tests de fonctionnalité sans condition ; les trois autres sont conditionnées par une configuration manuelle. Aucune d'entre elles n'est malveillante. Le danger qu'elles introduisent n'est pas celui de la malveillance, mais d'une capacité excessive. Leur 'périmètre d'explosion' — la portée de ce qu'elles peuvent faire avec les permissions qui leur sont accordées — est inutilement grand. Il ne s'agit pas nécessairement de skills Claude dangereuses à éviter à tout prix, mais elles nécessitent une manipulation prudente et une compréhension des permissions que vous accordez.

Accès trop large au système de fichiers

Un schéma courant consiste à demander des permissions sur le système de fichiers bien au-delà de ce dont la skill a besoin pour fonctionner. Un excellent exemple est UCTM Init, un initialisateur de projet pour le pipeline de plugins uc-taskmanager. Lors de la configuration, il présente une invite générique pour appliquer des "paramètres recommandés", ce qui inclut l'écriture de permissions étendues Read/Edit/Write(/**) dans le fichier de configuration local .claude/settings.local.json. Lors de notre exécution sur un projet test, cette seule approbation a effectué deux actions distinctes : elle a écrit les entrées génériques (wildcard) de lecture/édition/écriture, qui constituent le véritable périmètre d'explosion sur le système de fichiers, et elle a fusionné 34 permissions Bash nommées dans la configuration du projet. Les entrées Bash nommées constituent une liste blanche de commandes énumérées et sont la partie la plus défendable ; le wildcard est la partie à lire avant de cliquer sur oui. La skill fonctionne et réussit nos tests, mais la portée que vous approuvez est beaucoup plus large que la tâche à accomplir.

Jetons d'API perpétuels et sans portée définie

Un autre problème récurrent est la gestion des clés d'API. La skill Add Vercel, qui intègre les identifiants de déploiement Vercel dans les conteneurs d'agent NanoClaw, demande à l'utilisateur de créer un jeton d'API Vercel avec une portée "Full Account" et sans date d'expiration. Elle attribue ensuite ce jeton puissant à chaque agent. Un agent compromis ou bogué pourrait, en théorie, utiliser ce jeton pour lire, modifier ou supprimer n'importe quel projet, équipe ou configuration au sein de l'ensemble du compte Vercel. La solution est simple — créer un jeton à portée restreinte et le renouveler régulièrement — mais le chemin par défaut crée un risque important.

Le piège de --dangerously-skip-permissions

Claude Code inclut un flag, --dangerously-skip-permissions, qui ignore les invites de confirmation interactives pour une exécution ; la propre documentation d'Anthropic conseille de le restreindre à un conteneur ou une VM. C'est une fonctionnalité connue pour les utilisateurs avancés, mais nous avons trouvé plusieurs skills qui normalisent son utilisation, en l'intégrant dans des commandes par défaut ou des configurations persistantes. Une session interactive affiche une boîte de dialogue d'acceptation unique la première fois que ce mode est activé, ce qui est précisément ce qu'un paramètre de configuration persistant contourne. Le résultat transforme une dérogation délibérée et ponctuelle en un état permanent et invisible de sécurité réduite.

Skill	Contexte d'utilisation du flag	Risque
OMA Image	Commande par défaut du CLI du sous-agent	Un processus enfant s'exécute sans vérification des permissions.
Agentic OS Obsidian	Configurations persistantes du tableau de bord/terminal	Des déclencheurs non surveillés s'activent sans confirmation à chaque exécution.
Agy CLI	Modèle recommandé pour les exécutions déléguées	Normalise la désactivation d'une fonctionnalité de sécurité essentielle pour une utilisation courante.

Dans le cas de OMA Image, la commande canonique pour son sous-agent inclut le flag par défaut. Pour Agentic OS Obsidian, le flag est intégré dans les configurations persistantes pour les boutons du tableau de bord et les profils de terminal, ce qui signifie que des actions peuvent être déclenchées sans autres invites de sécurité. Agy CLI le recommande comme un modèle standard pour les exécutions déléguées. Bien que la documentation de la skill note le risque, son modèle d'utilisation courant désactive de fait un mécanisme de sécurité critique. Encore une fois, ce sont des outils utiles, mais leurs configurations par défaut sacrifient la sécurité au profit de la commodité d'une manière qui incite à la prudence.

Risques secondaires : gestion des données et abstractions non étanches

Au-delà des octrois de permissions explicites, nous avons également observé de mauvaises pratiques de sécurité qui augmentent la surface d'attaque d'un système ou divulguent des informations sensibles, même si elles ne constituent pas un malware actif.

Un exemple est AI Search Hub. Son script d'enveloppe (wrapper) fonctionne en copiant l'intégralité du répertoire de données utilisateur du navigateur — y compris les cookies et les sessions actives — dans un dossier de profil local ignoré par git (chrome_debug_profile_skill). Il expose également le protocole Chrome DevTools sur le port 9222 de la machine locale. Ce n'est pas de l'exfiltration ; les données ne quittent pas la machine locale. Cependant, cela crée une copie locale de données de session sensibles et ouvre un port de débogage puissant, élargissant le périmètre d'explosion pour tout autre processus local qui pourrait être compromis.

Un autre exemple est Google Ad Scraper. Cette skill passe son jeton d'API en tant que paramètre de requête d'URL (?token=...) plutôt que dans un en-tête Authorization. Les chaînes de requête sont le pire endroit pour placer un secret : elles se retrouvent dans l'historique du shell, les journaux d'accès du serveur et tout proxy sur le chemin. La même skill envoie également ce jeton à un point de terminaison tiers, api.gooseworks.ai, lorsqu'une clé correspondante est définie. Ce ne sont pas des actes malveillants, mais un manquement aux pratiques standard, et ils créent une exposition que vous n'avez pas sollicitée. Pour en savoir plus sur ce sujet, consultez notre vue d'ensemble de la sécurité des skills Claude.

L'aspect constructif : les skills qui améliorent la sécurité

L'écosystème des skills n'est pas seulement une source de risque potentiel ; c'est aussi une source d'outils puissants pour l'atténuer. Le même framework qui permet à une skill d'interagir avec votre système de fichiers lui permet également de l'auditer à la recherche de vulnérabilités. Nous avons testé plusieurs skills conçues spécifiquement pour les revues de sécurité.

Skill Security Auditor se démarque. Nous l'avons testé sur un fichier de 13 lignes contenant une injection SQL flagrante, une injection de commande et une clé d'API codée en dur. Ses scripts d'analyse ont identifié avec succès les trois vulnérabilités. En prime, il a également signalé un fichier .gitignore manquant, un problème qu'un examinateur humain n'avait pas vu.

De même, nous avons exécuté Code Health Check sur l'API Express délibérément boguée que la skill fournit dans son propre dépôt. Il a trouvé les huit problèmes intentionnels, qui comprenaient une injection SQL, un analyseur de configuration basé sur eval(), deux secrets codés en dur, une erreur ignorée et une fonction morte. Il a fourni des niveaux de gravité corrects et des citations précises de fichier et de numéro de ligne pour chacun.

Ces outils démontrent le revers de la médaille des capacités des skills. En accordant à une skill d'audit de confiance un accès contrôlé à votre code, vous pouvez automatiser certaines parties de votre processus de revue de sécurité. Vous pouvez trouver d'autres outils de ce type dans notre guide sur les skills Claude pour la revue de sécurité.

Comment vous protéger : un modèle de menace pratique

Étant donné que la menace principale est le sur-provisionnement des permissions plutôt que les malwares, la stratégie de défense change. Il s'agit moins d'antivirus que de discipline opérationnelle.

1. Présumez la bonne intention, vérifiez la portée : Le développeur de la skill que vous installez n'essaie probablement pas de vous pirater. Mais il a pu être négligent ou avoir privilégié la commodité à la sécurité. Lorsqu'une skill demande des permissions, lisez l'invite. Si elle demande un accès en écriture à l'ensemble de votre répertoire personnel pour ajouter une ligne à un seul fichier de configuration, refusez.

2. Privilégiez les skills à faible périmètre d'explosion : Recherchez des skills autonomes qui suivent le principe du moindre privilège. Un excellent exemple est Workthreads. C'est une skill autonome sans aucune dépendance. Elle n'appelle git que via execFileSync avec des arguments de tableau fixes pour empêcher l'injection de commande, et elle est livrée avec une rédaction déterministe et intégrée des secrets pour AWS, GitHub, Slack, OpenAI, Anthropic, les JWTs et les jetons bearer avant d'afficher toute sortie. Elle a été clairement conçue avec un périmètre d'explosion restreint et contrôlé à l'esprit.

3. Exécutez dans un bac à sable (sandbox) : N'exécutez pas une nouvelle skill inconnue sur votre base de code de production principale ou depuis votre répertoire personnel. Créez un répertoire dédié et jetable pour les tests. Utilisez Docker ou d'autres technologies de conteneurisation pour une isolation encore plus forte.

4. Fiez-vous à l'exécution, pas seulement au code : La seule façon d'être certain de ce que fait une skill est de l'exécuter et d'observer son comportement. C'est le principe fondamental de la méthodologie de SkillProof. Nous publions nos notes de test, y compris les avertissements de sécurité comme les cinq de cet article, pour chaque skill que nous exécutons.

Lectures complémentaires : la suite pratique de cet article est comment la déclaration allowed-tools d'une skill délimite réellement sa portée, ce qui est le levier sur lequel reposent la plupart des problèmes ci-dessus. Pour savoir comment l'écosystème de référencement plus large se décrit par rapport à ce qu'il vérifie, consultez notre analyse de la réalité des répertoires.

Chaque avertissement de sécurité cité ici est public sur la page de catalogue de la skill, à côté de son verdict et de son score, afin que vous puissiez consulter les preuves avant d'installer quoi que ce soit. Si vous préférez commencer avec un ensemble qui a déjà subi ce processus, notre Pack Sécurité & Revue de Code rassemble dix skills testées pour la revue de code, le débogage et les tests de contrat.