Het echte veiligheidsrisico van Claude-skills is geen malware

Bij ontwikkelaarstools zoals Claude-skills vertaalt de angst voor beveiligingsproblemen zich in een zoektocht naar klassieke malware: verborgen credential stealers, geobfusceerde shell-commando's en andere heimelijke payloads. Die angst is terecht. Snyk's ToxicSkills-audit scande per 5 februari 2026 3.984 skills van ClawHub en skills.sh en vond prompt-injection-patronen in 36% van het ecosysteem, 534 skills met kritieke beveiligingsproblemen en 76 kwaadaardige payloads die door menselijke review werden bevestigd, waarvan er 8 op het moment van publicatie nog live stonden op clawhub.ai. Bij het parallelle ClawHavoc-incident werden 341 kwaadaardige skills uit de registry van ClawHub verwijderd. Kwaadaardige agent-skills zijn niet hypothetisch.

Het is dus belangrijk om precies te zijn over wat we hebben gevonden, en wat ons aantal wel en niet betekent. Bij SkillProof installeren en voeren we elke skill uit die we listen, en publiceren vervolgens het resultaat, geslaagd of niet. Op het moment van schrijven hebben we 1.672 skills getest: 1045 zijn geslaagd (een slagingspercentage van 63%), 560 vereisen handmatige configuratie, en 67 scoorden lager dan een kale Claude zonder skill. We zijn ons niet bewust van een andere directory die de onvoldoende resultaten naast de geslaagde publiceert.

In die 1.672 uitgevoerde tests vonden we nul gevallen van verborgen malware. Dat resultaat heeft een grote kanttekening: onze catalogus is geen willekeurige steekproef van een openbare registry. Kandidaten worden vooraf gescreend op kwaliteit voordat ze een testplek krijgen, repositories van lage kwaliteit en spam worden op een blokkadelijst gehouden, en de skills die een gepubliceerd oordeel halen, zijn degenen die waarschijnlijk al legitiem zijn. Snyk nam een steekproef van de registry; wij nemen een steekproef van het deel dat de moeite waard is om te installeren. Beide cijfers zijn waar, en ze beantwoorden verschillende vragen.

Waar onze steekproef goed voor is, is de vraag die niemand anders beantwoordt: als je de overduidelijke malware eruit hebt gefilterd, waar moet je je dan nog zorgen over maken? Het antwoord, reproduceerbaar, is de 'blast radius' van permissies en capabilities van legitieme, nuttige skills. Dat risico is moeilijker te scannen, omdat het grotendeels schuilt in wat een skill je vraagt goed te keuren bij installatie en tijdens runtime.

Wat we niet vonden: de afwezigheid van verborgen payloads

Laten we direct zijn. In meer dan zestienhonderd unieke skill-executies vonden we:

• Nul gevallen van heimelijke exfiltratie van credentials naar een onbekende server.
• Nul gevallen van een curl | sh-payload verborgen in de bestanden van een skill zelf. Verschillende skills leveren wel een curl | bash-installer in hun repository-README, en in één geval wordt de installatie van de externe CLI helemaal niet genoemd in de SKILL.md. Dit zijn openbaar gemaakte installatiestappen die je kunt lezen voordat je ze uitvoert, geen verborgen payloads, maar ze zijn het opmerken waard.
• Nul gevallen van met base64 geobfusceerde payloads of andere klassieke obfuscatie-technieken bedoeld om de intentie te verbergen.
• Nul verborgen instructies in een SKILL.md-bestand die afweken van het openbare doel van de skill.

De zoektocht naar concrete malware-voorbeelden in onze geteste set levert niets op. Dat betekent niet dat scannen nutteloos is. Het betekent dat de scanners die de meeste mensen gebruiken, zijn afgestemd op de verkeerde signatures. Een tool die zoekt naar kwaadaardige codepatronen vindt niets in onze steekproef; een tool die is afgestemd op permissie- en capability-patronen zou het meeste vangen van wat we hebben gelogd, omdat die patronen gewoon in de tekst van de bestanden staan. Het verschil zit in waar je naar zoekt, niet of het zoeken werkt. Executie vangt nog steeds wat beide niet vinden: welke permissies een skill daadwerkelijk vraagt wanneer je hem uitvoert, en wat hij naar je configuratie schrijft zodra je ja zegt. Voor een diepere kijk op ons proces, zie hoe we Claude-skills testen.

De echte dreiging: 'permission blast radius' bij legitieme skills

De belangrijkste beveiligingsproblemen die we vonden, zaten in skills die verder functioneel en waardevol zijn. Twee van de vijf onderstaande skills slagen direct voor onze functionaliteitstests; de andere drie vereisen eerst configuratie ('setup-gated'). Geen ervan is kwaadaardig. Het gevaar dat ze introduceren is niet kwaadwilligheid, maar overmatige capability. Hun 'blast radius' — de scope van wat ze kunnen doen met de permissies die ze krijgen — is onnodig groot. Dit zijn niet per se gevaarlijke Claude-skills die je volledig moet vermijden, maar ze vereisen een zorgvuldige aanpak en begrip van de permissies die je verleent.

Te ruime toegang tot het bestandssysteem

Een veelvoorkomend patroon is het aanvragen van bestandssysteem-permissies die veel verder gaan dan wat de skill nodig heeft om te functioneren. Een goed voorbeeld is UCTM Init, een project-initializer voor de uc-taskmanager plugin-pipeline. Tijdens de setup toont het een generieke prompt om "aanbevolen instellingen" toe te passen, wat inhoudt dat brede Read/Edit/Write(/**)-permissies worden weggeschreven naar het lokale .claude/settings.local.json-configuratiebestand. In onze test met een scratch-project deed die ene goedkeuring twee afzonderlijke dingen: het schreef de wildcard read/edit/write-entries, die de feitelijke 'filesystem blast radius' vormen, en het voegde 34 benoemde Bash-permissies samen in de projectconfiguratie. De benoemde Bash-entries zijn een opgesomde 'command allowlist' en vormen de beter verdedigbare helft; de wildcard is het deel dat je moet lezen voordat je op 'ja' klikt. De skill werkt, en slaagt voor onze tests, maar de scope die je goedkeurt is veel breder dan de taak die voor je ligt.

Ongescopete, permanente API-tokens

Een ander terugkerend probleem is de omgang met API-keys. De skill Add Vercel, die Vercel deploy-credentials koppelt aan NanoClaw agent-containers, instrueert de gebruiker om een Vercel API-token aan te maken met "Full Account"-scope en zonder vervaldatum. Vervolgens wijst het deze krachtige token toe aan elke agent. Een gecompromitteerde of buggy agent zou in theorie deze token kunnen gebruiken om elk project, team of configuratie binnen het gehele Vercel-account te lezen, wijzigen of verwijderen. De oplossing is eenvoudig — maak een nauw gescopete token aan en roteer deze — maar het standaardpad creëert een aanzienlijk risico.

De --dangerously-skip-permissions 'footgun'

Claude Code bevat een flag, --dangerously-skip-permissions, die de interactieve bevestigingsprompts voor een run overslaat; Anthropic's eigen documentatie adviseert het gebruik ervan te beperken tot een container of VM. Het is een bekende feature voor power-users, maar we vonden verschillende skills die het gebruik ervan normaliseren door het op te nemen in standaardcommando's of persistente configuraties. Een interactieve sessie toont een eenmalig acceptatiedialoogvenster de eerste keer dat deze modus wordt geactiveerd, wat precies is wat een persistente configuratie-instelling omzeilt. Het resultaat verandert een bewuste, per-run override in een onzichtbare, permanente staat van verminderde beveiliging.

Skill	Context van flag-gebruik	Risico
OMA Image	Standaardcommando van sub-agent	Een child process draait zonder permissiecontroles.
Agentic OS Obsidian	Persistente dashboard/terminal-configuraties	Onbeheerde triggers worden geactiveerd zonder per-run bevestiging.
Agy CLI	Aanbevolen patroon voor gedelegeerde runs	Normaliseert het uitschakelen van een kernbeveiligingsfunctie voor routinegebruik.

In het geval van OMA Image bevat het canonieke commando voor zijn sub-agent de flag standaard. Voor Agentic OS Obsidian is de flag ingebakken in persistente configuraties voor dashboardknoppen en terminalprofielen, wat betekent dat acties kunnen worden getriggerd zonder verdere beveiligingsprompts. Agy CLI beveelt het aan als een standaardpatroon voor gedelegeerde runs. Hoewel de documentatie van de skill het risico vermeldt, schakelt het gangbare gebruikspatroon in feite een cruciaal veiligheidsmechanisme uit. Nogmaals, dit zijn nuttige tools, maar hun standaardconfiguraties ruilen veiligheid in voor gemak op een manier die voorzichtigheid vereist.

Secundaire risico's: dataverwerking en 'leaky abstractions'

Naast expliciete permissies zagen we ook slechte beveiligingspraktijken die het aanvalsoppervlak van een systeem vergroten of gevoelige informatie lekken, zelfs als ze geen actieve malware vormen.

Een voorbeeld is AI Search Hub. Het wrapper-script kopieert de volledige user data directory van de gebruiker's browser — inclusief cookies en actieve sessies — naar een lokale, gitignored profielmap (chrome_debug_profile_skill). Het stelt ook het Chrome DevTools Protocol bloot op poort 9222 op de lokale machine. Dit is geen exfiltratie; de data verlaat de lokale machine niet. Het creëert echter een lokale kopie van gevoelige sessiedata en opent een krachtige debugging-poort, wat de 'blast radius' vergroot voor elk ander lokaal proces dat gecompromitteerd zou kunnen zijn.

Een ander voorbeeld is Google Ad Scraper. Deze skill geeft zijn API-token door als een URL query parameter (?token=...) in plaats van in een Authorization-header. Query strings zijn de slechtste plek voor een secret: ze komen terecht in shell-geschiedenis, server-access-logs en elke proxy onderweg. Dezelfde skill stuurt die token ook naar een extern eindpunt, api.gooseworks.ai, wanneer een corresponderende key is ingesteld. Dit zijn geen kwaadaardige handelingen, maar een falen om de standaardpraktijk te volgen, en ze creëren blootstelling waar je niet om hebt gevraagd. Voor meer over dit onderwerp, zie ons overzicht van Claude-skills beveiliging.

De constructieve kant: skills die de beveiliging verbeteren

Het skill-ecosysteem is niet alleen een bron van potentieel risico; het is ook een bron van krachtige tools om het te beperken. Hetzelfde framework dat een skill in staat stelt om met je bestandssysteem te interageren, stelt een skill ook in staat om het te auditen op kwetsbaarheden. We hebben verschillende skills getest die specifiek zijn ontworpen voor security reviews.

Skill Security Auditor is een uitblinker. We hebben het getest op een bestand van 13 regels met overduidelijke SQL-injection, command injection en een hardcoded API-key. De analysescripts identificeerden met succes alle drie de kwetsbaarheden. Als bonus signaleerde het ook een ontbrekend .gitignore-bestand, een probleem dat een menselijke reviewer over het hoofd had gezien.

Op dezelfde manier hebben we Code Health Check gedraaid tegen de opzettelijk buggy Express API die de skill in zijn eigen repository meelevert. Het vond alle acht geplaatste problemen, waaronder SQL-injection, een op eval() gebaseerde config-parser, twee hardcoded secrets, een 'swallowed error' en een dode functie. Het gaf voor elk de juiste 'severity levels' en precieze verwijzingen naar bestand en regelnummer.

Deze tools demonstreren de keerzijde van de capabilities van skills. Door een vertrouwde audit-skill gecontroleerde toegang tot je code te geven, kun je delen van je security review-proces automatiseren. Meer van dit soort tools vind je in onze gids voor Claude-skills voor security review.

Hoe je jezelf beschermt: een praktisch dreigingsmodel

Gezien het feit dat de primaire dreiging overmatige permissies zijn in plaats van malware, verandert de verdedigingsstrategie. Het gaat minder om antivirus en meer om operationele discipline.

1. Ga uit van goede bedoelingen, verifieer de scope: De ontwikkelaar van de skill die je installeert, probeert je waarschijnlijk niet te hacken. Maar ze kunnen onzorgvuldig zijn geweest of gemak boven veiligheid hebben gesteld. Wanneer een skill om permissies vraagt, lees dan de prompt. Als het schrijftoegang tot je hele home-directory vraagt om een regel aan één configuratiebestand toe te voegen, weiger dit dan.

2. Geef de voorkeur aan skills met een kleine 'blast radius': Zoek naar skills die op zichzelf staan en het 'principle of least privilege' volgen. Een goed voorbeeld hiervan is Workthreads. Het is een opzichzelfstaande skill zonder dependencies. Het roept alleen git aan via execFileSync met vaste array-argumenten om command injection te voorkomen, en het wordt geleverd met ingebouwde, deterministische 'secret redaction' voor AWS, GitHub, Slack, OpenAI, Anthropic, JWTs en bearer tokens voordat er output wordt geprint. Het is duidelijk gebouwd met een kleine, gecontroleerde 'blast radius' in gedachten.

3. Draai je runs in een sandbox: Draai een nieuwe, onbekende skill niet op je primaire productie-codebase of vanuit je home-directory. Maak een speciale, wegwerp-directory aan om te testen. Gebruik Docker of andere containerisatietechnologieën voor een nog sterkere afbakening.

4. Vertrouw op executie, niet alleen op code: De enige manier om zeker te weten wat een skill doet, is door hem uit te voeren en zijn gedrag te observeren. Dit is het basisprincipe van de SkillProof methodologie. We publiceren onze testnotities, inclusief beveiligingswaarschuwingen zoals de vijf in dit artikel, voor elke skill die we draaien.

Gerelateerde lectuur: het praktische vervolg op dit artikel is hoe de allowed-tools-declaratie van een skill daadwerkelijk de scope bepaalt van wat het kan aanraken, wat de hefboom is waar de meeste van de bovenstaande problemen op neerkomen. Voor hoe het bredere ecosysteem van listings zichzelf beschrijft versus wat het verifieert, zie onze directory reality check.

Elke hier geciteerde beveiligingswaarschuwing is openbaar op de eigen cataloguspagina van de skill, naast het oordeel en de score, zodat je het bewijs kunt lezen voordat je iets installeert. Als je liever begint met een set die dit proces al heeft doorlopen, verzamelt ons Security & Code Review Pack tien geteste skills voor code review, debugging en contract testing.