Efter at have kørt 1.672 Claude Skills er den reelle sikkerhedsrisiko ikke malware

Når det gælder udviklingsværktøjer som Claude skills, omsættes sikkerhedsfrygt til en søgen efter klassisk malware: skjulte credential-tyve, obfuskerede shell-kommandoer og andre skjulte payloads. Den frygt er velbegrundet. Snyks ToxicSkills-audit scannede 3.984 skills fra ClawHub og skills.sh pr. 5. februar 2026 og fandt prompt-injection-mønstre i 36% af økosystemet, 534 skills med kritiske sikkerhedsproblemer og 76 ondsindede payloads bekræftet ved manuel gennemgang, hvoraf 8 stadig var live på clawhub.ai ved udgivelsen. Den parallelle ClawHavoc-hændelse så 341 ondsindede skills blive trukket tilbage fra ClawHubs register. Ondsindede agent-skills er ikke hypotetiske.

Derfor er det værd at være præcis omkring, hvad vi fandt, og hvad vores tal betyder og ikke betyder. Hos SkillProof installerer og eksekverer vi alle skills, vi lister, og publicerer derefter resultatet, uanset om det er bestået eller ej. I skrivende stund har vi testet 1.672 skills: 1045 bestod (en beståelsesrate på 63%), 560 kræver manuel opsætning, og 67 scorede lavere end en ren Claude uden installeret skill. Vi kender ikke til andre biblioteker, der publicerer deres fejlende resultater side om side med de beståede.

På tværs af disse 1.672 eksekverede tests fandt vi nul tilfælde af skjult malware. Det resultat kommer med en stor stjerne: vores katalog er ikke en tilfældig stikprøve fra et offentligt register. Kandidater bliver forhåndsscreenet for kvalitet, før de overhovedet når en testplads, lav-kvalitets og spam-repositories holdes på en blokeringsliste, og de skills, der overlever til en publiceret dom, er dem, der allerede sandsynligvis er legitime. Snyk tog en stikprøve af registret; vi tager en stikprøve af den del, der er værd at installere. Begge tal er sande, og de besvarer forskellige spørgsmål.

Det, vores stikprøve er god til, er at besvare det spørgsmål, ingen andre besvarer: når man har filtreret den åbenlyse malware fra, hvad er der så tilbage at bekymre sig om? Svaret er, reproducerbart, skadesomfanget (blast radius) af tilladelser og kapabiliteter i legitime, nyttige skills. Den risiko er sværere at scanne for, fordi det meste af den ligger i, hvad en skill beder dig om at godkende ved installation og under kørsel.

Hvad vi ikke fandt: Fraværet af skjulte payloads

Lad os være direkte. I over seksten hundrede unikke skill-eksekveringer fandt vi:

• Nul tilfælde af skjult eksfiltrering af credentials til en ukendt server.
• Nul tilfælde af en curl | sh payload skjult i en skills egne filer. Flere skills leverer dog en curl | bash installer i deres repositorys README, og i et tilfælde er tredjeparts CLI-installationen slet ikke nævnt i SKILL.md. Disse er oplyste installationstrin, man kan læse før kørsel, ikke skjulte payloads, men de er værd at bemærke.
• Nul tilfælde af base64-obfuskerede payloads eller andre klassiske obfuskeringsteknikker designet til at skjule hensigt.
• Nul skjulte instruktioner i en SKILL.md-fil, der afveg fra skill'ens offentlige formål.

Søgningen efter konkrete malware-eksempler i vores testede sæt er resultatløs. Det betyder ikke, at scanning er nytteløst. Det betyder, at de scannere, de fleste bruger, er indstillet til de forkerte signaturer. Et værktøj, der leder efter ondsindede kodemønstre, returnerer intet på vores stikprøve; et værktøj, der er indstillet til tilladelses- og kapabilitetsmønstre, ville fange det meste af, hvad vi loggede, fordi disse mønstre står direkte i filteksten. Hullet ligger i, hvad man leder efter, ikke om det at lede virker. Eksekvering fanger stadig det, som ingen af delene finder: hvilke tilladelser en skill rent faktisk anmoder om, når du kører den, og hvad den skriver til din konfiguration, når du siger ja. For et dybere indblik i vores proces, se hvordan vi tester Claude skills.

Den reelle trussel: Skadesomfang af tilladelser i legitime skills

De mest betydningsfulde sikkerhedsproblemer, vi fandt, var i skills, der ellers er funktionelle og værdifulde. To af de fem skills nedenfor består vores funktionalitetstests direkte; de andre tre kræver manuel opsætning. Ingen af dem er ondsindede. Faren, de introducerer, er ikke ondsindethed, men overdreven kapabilitet. Deres 'blast radius' — omfanget af, hvad de kan gøre med de tilladelser, de får — er unødvendigt stort. Disse er ikke nødvendigvis farlige Claude skills, man helt skal undgå, men de kræver omhyggelig håndtering og en forståelse af de tilladelser, man giver.

For bred adgang til filsystemet

Et almindeligt mønster er at anmode om filsystemtilladelser langt ud over, hvad skill'en har brug for for at fungere. Et godt eksempel er UCTM Init, en projekt-initializer til uc-taskmanager plugin-pipelinen. Under opsætning præsenterer den en generisk prompt om at anvende "anbefalede indstillinger", hvilket inkluderer at skrive brede Read/Edit/Write(/**)-tilladelser til den lokale .claude/settings.local.json-konfigurationsfil. I vores testkørsel på et nyt projekt gjorde den ene godkendelse to separate ting: den skrev wildcard-indgangene for læse/redigere/skrive, som er det faktiske skadesomfang for filsystemet, og den flettede 34 navngivne Bash-tilladelser ind i projektets konfiguration. De navngivne Bash-indgange er en opregnet allow-liste for kommandoer og er den mere forsvarlige halvdel; wildcard-delen er den, man skal læse, før man klikker ja. Skill'en virker, og den består vores tests, men det omfang, du godkender, er meget bredere end den opgave, du står overfor.

API-tokens uden afgrænset scope og udløb

Et andet tilbagevendende problem er håndteringen af API-nøgler. Skill'en Add Vercel, som forbinder Vercel deploy-credentials til NanoClaw agent-containere, instruerer brugeren i at oprette et Vercel API-token med "Full Account"-scope og ingen udløbsdato. Den tildeler derefter dette kraftfulde token til hver agent. En kompromitteret eller fejlbehæftet agent kunne i teorien bruge dette token til at læse, ændre eller slette ethvert projekt, team eller konfiguration inden for hele Vercel-kontoen. Løsningen er simpel — opret et snævert afgrænset token og roter det — men standardvejen skaber en betydelig risiko.

Fodfælden med --dangerously-skip-permissions

Claude Code inkluderer et flag, --dangerously-skip-permissions, som springer de interaktive bekræftelsesprompter over for en kørsel; Anthropics egen dokumentation anbefaler at begrænse det til en container eller VM. Det er en kendt power-user-funktion, men vi fandt flere skills, der normaliserer brugen af den ved at indbygge den i standardkommandoer eller persisterede konfigurationer. En interaktiv session viser en engangsgodkendelsesdialog første gang, tilstanden aktiveres, hvilket er præcis, hvad en persisteret konfigurationsindstilling omgår. Resultatet forvandler en bevidst tilsidesættelse pr. kørsel til en usynlig, permanent tilstand af nedsat sikkerhed.

Skill	Kontekst for flag-brug	Risiko
OMA Image	Standardkommando for under-agent CLI	En underproces kører uden tilladelsestjek.
Agentic OS Obsidian	Persisterede dashboard/terminal-konfigurationer	Uovervågede triggere affyres uden bekræftelse pr. kørsel.
Agy CLI	Anbefalet mønster for delegerede kørsler	Normaliserer deaktivering af en central sikkerhedsfunktion til rutinemæssig brug.

I tilfældet med OMA Image inkluderer den kanoniske kommando for dens under-agent flaget som standard. For Agentic OS Obsidian er flaget indbygget i persisterede konfigurationer for dashboard-knapper og terminalprofiler, hvilket betyder, at handlinger kan udløses uden yderligere sikkerhedsprompter. Agy CLI anbefaler det som et standardmønster for delegerede kørsler. Selvom skill'ens dokumentation bemærker risikoen, deaktiverer dens almindelige brugsmønster reelt en kritisk sikkerhedsmekanisme. Igen, dette er nyttige værktøjer, men deres standardkonfigurationer bytter sikkerhed for bekvemmelighed på en måde, der kræver forsigtighed.

Sekundære risici: Datahåndtering og lækkende abstraktioner

Ud over eksplicitte tilladelser observerede vi også dårlig sikkerhedspraksis, der øger et systems angrebsflade eller lækker følsomme oplysninger, selvom det ikke udgør aktiv malware.

Et eksempel er AI Search Hub. Dets wrapper-script fungerer ved at kopiere brugerens hele browser-brugerdatamappe — inklusiv cookies og aktive sessioner — ind i en lokal, gitignored profilmappe (chrome_debug_profile_skill). Det eksponerer også Chrome DevTools Protocol på port 9222 på den lokale maskine. Dette er ikke eksfiltrering; dataene forlader ikke den lokale maskine. Det skaber dog en lokal kopi af følsomme sessionsdata og åbner en kraftfuld debugging-port, hvilket udvider skadesomfanget for enhver anden lokal proces, der måtte blive kompromitteret.

Et andet eksempel er Google Ad Scraper. Denne skill sender sit API-token som en URL-query-parameter (?token=...) i stedet for i en Authorization-header. Query-strenge er det værste sted at placere en hemmelighed: de ender i shell-historik, server-adgangslogs og enhver proxy på vejen. Den samme skill sender også dette token til et tredjeparts-endpoint, api.gooseworks.ai, når en tilsvarende nøgle er sat. Dette er ikke ondsindede handlinger, men en manglende overholdelse af standardpraksis, og de skaber en eksponering, du ikke har bedt om. For mere om dette emne, se vores oversigt over Claude skills-sikkerhed.

Den konstruktive side: Skills der forbedrer sikkerheden

Skill-økosystemet er ikke kun en kilde til potentiel risiko; det er også en kilde til kraftfulde værktøjer til at afbøde den. Det samme framework, der tillader en skill at interagere med dit filsystem, tillader også en skill at auditere det for sårbarheder. Vi har testet flere skills, der er designet specifikt til sikkerhedsgennemgange.

Skill Security Auditor er enestående. Vi testede den mod en 13-linjers fil, der indeholdt åbenlys SQL-injection, command injection og en hardcodet API-nøgle. Dens analyse-scripts identificerede succesfuldt alle tre sårbarheder. Som en bonus markerede den også en manglende .gitignore-fil, et problem en menneskelig reviewer havde overset.

Tilsvarende kørte vi Code Health Check mod den bevidst fejlbehæftede Express API, som skill'en leverer i sit eget repository. Den fandt alle otte plantede problemer, som inkluderede SQL-injection, en eval()-baseret config-parser, to hardcodede hemmeligheder, en ignoreret fejl og en død funktion. Den leverede korrekte alvorlighedsgrader og præcise fil- og linjenummerhenvisninger for hver.

Disse værktøjer demonstrerer den anden side af skill-kapabiliteter. Ved at give en betroet auditerings-skill kontrolleret adgang til din kode, kan du automatisere dele af din sikkerhedsgennemgangsproces. Du kan finde flere værktøjer som disse i vores guide til Claude skills til sikkerhedsgennemgang.

Sådan beskytter du dig selv: En praktisk trusselsmodel

Givet at den primære trussel er over-permissioning snarere end malware, ændres den defensive strategi. Det handler mindre om antivirus og mere om operationel disciplin.

1. Antag gode intentioner, verificer omfang: Udvikleren af den skill, du installerer, prøver sandsynligvis ikke at hacke dig. Men de kan have været skødesløse eller prioriteret bekvemmelighed over sikkerhed. Når en skill beder om tilladelser, så læs prompten. Hvis den beder om skriveadgang til hele din hjemmemappe for at tilføje en linje til en enkelt konfigurationsfil, så afvis det.

2. Foretræk skills med et lille skadesomfang (blast radius): Kig efter skills, der er selvstændige og følger princippet om mindste privilegium. Et godt eksempel på dette er Workthreads. Det er en selvstændig skill uden afhængigheder. Den kalder kun git via execFileSync med faste array-argumenter for at forhindre command injection, og den leveres med indbygget, deterministisk redigering af hemmeligheder for AWS, GitHub, Slack, OpenAI, Anthropic, JWTs og bearer tokens, før den udskriver noget output. Den er tydeligt bygget med et lille, kontrolleret skadesomfang for øje.

3. Kør i en sandbox: Kør ikke en ny, ukendt skill på din primære produktionskodebase eller fra din hjemmemappe. Opret en dedikeret, engangsmappe til test. Brug Docker eller andre container-teknologier for en endnu stærkere afgrænsning.

4. Stol på eksekvering, ikke kun kode: Den eneste måde at være sikker på, hvad en skill gør, er at køre den og observere dens adfærd. Dette er det grundlæggende princip i SkillProofs metodologi. Vi publicerer vores testnoter, inklusiv sikkerhedsadvarsler som de fem i denne artikel, for hver skill vi kører.

Relateret læsning: den praktiske opfølgning på denne artikel er hvordan en skills allowed-tools-erklæring reelt afgrænser, hvad den kan røre ved, hvilket er det håndtag, de fleste af ovenstående problemer bunder i. For hvordan det bredere økosystem af lister beskriver sig selv versus hvad det verificerer, se vores directory reality check.

Hver sikkerhedsadvarsel, der er citeret her, er offentlig på skill'ens egen katalogside, sammen med dens resultat og score, så du kan læse beviserne, før du installerer noget. Hvis du hellere vil starte med et sæt, der allerede har været igennem dette, samler vores Security & Code Review Pack ti testede skills til kodegennemgang, debugging og kontrakt-test.