Efter att ha kört 1 672 Claude-skills är den verkliga säkerhetsrisken inte skadlig kod

När det gäller utvecklarverktyg som Claude-skills, översätts säkerhetsrädsla till ett sökande efter klassisk skadlig kod: dolda verktyg för att stjäla inloggningsuppgifter, obfuskerade skalkommandon och andra dolda nyttolaster. Den rädslan är välgrundad. Snyks ToxicSkills-granskning skannade 3 984 skills från ClawHub och skills.sh den 5 februari 2026 och fann mönster för 'prompt-injection' i 36% av ekosystemet, 534 skills med kritiska säkerhetsproblem och 76 skadliga nyttolaster bekräftade genom manuell granskning, varav 8 fortfarande var aktiva på clawhub.ai vid publicering. Den parallella ClawHavoc-incidenten såg 341 skadliga skills dras tillbaka från ClawHubs register. Skadliga agent-skills är inte hypotetiska.

Därför är det värt att vara exakt med vad vi fann, och vad vår siffra betyder och inte betyder. På SkillProof installerar och exekverar vi varje skill vi listar, och publicerar sedan resultatet, godkänt eller ej. I skrivande stund har vi testat 1 672 skills: 1045 godkändes (en godkännandegrad på 63%), 560 kräver manuell konfiguration, och 67 presterade sämre än en ren Claude utan någon skill installerad. Vi känner inte till något annat register som publicerar sina underkända resultat vid sidan av de godkända.

I dessa 1 672 exekverade tester fann vi noll fall av dold skadlig kod. Det resultatet kommer med en stor asterisk: vår katalog är inte ett slumpmässigt urval från ett offentligt register. Kandidater förhandsgranskas för kvalitet innan de ens når en testplats, lågkvalitativa och spam-repositories hålls på en blockeringslista, och de skills som överlever till ett publicerat utlåtande är de som redan sannolikt är legitima. Snyk gjorde ett urval från registret; vi gör ett urval från den del som är värd att installera. Båda siffrorna är sanna, och de besvarar olika frågor.

Vad vårt urval är bra för är frågan ingen annan besvarar: när du har filtrerat bort den uppenbara skadliga koden, vad finns kvar att oroa sig för? Svaret, reproducerbart, är påverkansområdet för behörigheter och kapabiliteter hos legitima, användbara skills. Den risken är svårare att skanna efter, eftersom det mesta av den ligger i vad en skill ber dig godkänna vid installation och vid körning.

Vad vi inte fann: Frånvaron av dolda nyttolaster

Låt oss vara direkta. I över sextonhundra unika skill-exekveringar fann vi:

• Noll fall av dold exfiltrering av inloggningsuppgifter till en okänd server.
• Noll fall av en curl | sh-nyttolast gömd i en skills egna filer. Flera skills levererar en curl | bash-installerare i sin repository-README, och i ett fall nämns tredjeparts-CLI-installationen aldrig i SKILL.md överhuvudtaget. Dessa är redovisade installationssteg du kan läsa innan du kör, inte dolda nyttolaster, men de är värda att notera.
• Noll fall av base64-obfuskerade nyttolaster eller andra klassiska obfuskeringstekniker utformade för att dölja avsikt.
• Noll dolda instruktioner i en SKILL.md-fil som avvek från skillens offentliga syfte.

Sökandet efter konkreta exempel på skadlig kod i vår testade uppsättning ger inga resultat. Vad det inte betyder är att skanning är meningslöst. Det betyder att de skannrar de flesta använder är inställda på fel signaturer. Ett verktyg som letar efter mönster för skadlig kod returnerar ingenting på vårt urval; ett verktyg inställt på mönster för behörigheter och kapabiliteter skulle fånga det mesta av vad vi loggade, eftersom dessa mönster finns direkt i filtexten. Glappet är vad du letar efter, inte om letandet fungerar. Exekvering fångar fortfarande det som inget av dem hittar: vilka behörigheter en skill faktiskt begär när du kör den, och vad den skriver till din konfiguration när du har sagt ja. För en djupare titt på vår process, se hur vi testar Claude-skills.

Det verkliga hotet: Behörigheters påverkansområde i legitima skills

De mest betydande säkerhetsproblemen vi fann var i skills som i övrigt är funktionella och värdefulla. Två av de fem skills nedan klarar våra funktionstester direkt; de andra tre kräver manuell konfiguration. Ingen av dem är skadlig. Faran de introducerar är inte illvilja, utan överdriven kapabilitet. Deras 'blast radius' – räckvidden för vad de kan göra med de behörigheter de beviljas – är onödigt stor. Dessa är inte nödvändigtvis farliga Claude-skills att undvika helt, men de kräver noggrann hantering och en förståelse för de behörigheter du beviljar.

Överdrivet bred filsystemsåtkomst

Ett vanligt mönster är att begära filsystemsbehörigheter långt utöver vad som krävs för skillens funktion. Ett utmärkt exempel är UCTM Init, en projektinitialiserare för uc-taskmanager-plugin-pipelinen. Under konfigurationen visas en generisk uppmaning att tillämpa "rekommenderade inställningar", vilket inkluderar att skriva breda Read/Edit/Write(/**)-behörigheter till den lokala konfigurationsfilen .claude/settings.local.json. I vår körning med ett testprojekt gjorde det enda godkännandet två separata saker: det skrev wildcard-posterna för läs/redigera/skriv, vilket är den faktiska 'blast radius' för filsystemet, och det slog samman 34 namngivna Bash-behörigheter i projektets konfiguration. De namngivna Bash-posterna är en uppräknad tillåtelselista för kommandon och är den mer försvarbara halvan; wildcard-posten är den del man bör läsa innan man klickar ja. Skillen fungerar, och den klarar våra tester, men omfattningen du godkänner är mycket bredare än uppgiften framför dig.

Odefinierade, eviga API-tokens

Ett annat återkommande problem är hanteringen av API-nycklar. Skillen Add Vercel, som kopplar Vercel-deploy-inloggningsuppgifter till NanoClaw-agent-containrar, instruerar användaren att skapa en Vercel API-token med "Full Account"-omfattning och inget utgångsdatum. Den tilldelar sedan denna kraftfulla token till varje agent. En komprometterad eller buggig agent skulle i teorin kunna använda denna token för att läsa, ändra eller radera vilket projekt, team eller konfiguration som helst inom hela Vercel-kontot. Lösningen är enkel – skapa en snävt definierad token och rotera den – men standardvägen skapar en betydande risk.

Fallgropen --dangerously-skip-permissions

Claude Code inkluderar en flagga, --dangerously-skip-permissions, som hoppar över de interaktiva bekräftelsefrågorna för en körning; Anthropics egen dokumentation rekommenderar att begränsa den till en container eller VM. Det är en känd funktion för avancerade användare ('power-user'), men vi fann flera skills som normaliserar dess användning genom att baka in den i standardkommandon eller beständiga konfigurationer. En interaktiv session visar en engångsdialog för godkännande första gången läget aktiveras, vilket är precis vad en beständig konfigurationsinställning kringgår. Resultatet förvandlar en avsiktlig, per-körning-åsidosättning till ett osynligt, stående tillstånd av sänkt säkerhet.

Skill	Kontext för flagganvändning	Risk
OMA Image	Standardkommando för sub-agent CLI	En barnprocess körs utan behörighetskontroller.
Agentic OS Obsidian	Beständiga konfigurationer för instrumentpanel/terminal	Obevakade utlösare aktiveras utan bekräftelse per körning.
Agy CLI	Rekommenderat mönster för delegerade körningar	Normaliserar inaktivering av en central säkerhetsfunktion för rutinmässig användning.

I fallet med OMA Image inkluderar det kanoniska kommandot för dess sub-agent flaggan som standard. För Agentic OS Obsidian är flaggan inbakad i beständiga konfigurationer för instrumentpanelsknappar och terminalprofiler, vilket innebär att åtgärder kan utlösas utan ytterligare säkerhetsfrågor. Agy CLI rekommenderar det som ett standardmönster för delegerade körningar. Även om skillens dokumentation noterar risken, inaktiverar dess vanliga användningsmönster i praktiken en kritisk säkerhetsmekanism. Återigen, detta är användbara verktyg, men deras standardkonfigurationer byter säkerhet mot bekvämlighet på ett sätt som motiverar försiktighet.

Sekundära risker: Datahantering och läckande abstraktioner

Utöver explicita behörighetsbeviljanden observerade vi också dåliga säkerhetsrutiner som ökar ett systems attackyta eller läcker känslig information, även om de inte utgör aktiv skadlig kod.

Ett exempel är AI Search Hub. Dess omslagsskript fungerar genom att kopiera användarens hela webbläsares användardatakatalog – inklusive cookies och aktiva sessioner – till en lokal, gitignorerad profilmapp (chrome_debug_profile_skill). Det exponerar också Chrome DevTools Protocol på port 9222 på den lokala maskinen. Detta är inte exfiltrering; datan lämnar inte den lokala maskinen. Det skapar dock en lokal kopia av känslig sessionsdata och öppnar en kraftfull felsökningsport, vilket utökar påverkansområdet ('blast radius') för alla andra lokala processer som kan vara komprometterade.

Ett annat exempel är Google Ad Scraper. Denna skill skickar sin API-token som en URL-frågeparameter (?token=...) istället för i en Authorization-header. Frågesträngar är det sämsta stället att placera en hemlighet: de hamnar i skalhistorik, serverns åtkomstloggar och alla proxyservrar på vägen. Samma skill skickar också den token till en tredjeparts-endpoint, api.gooseworks.ai, när en motsvarande nyckel är satt. Dessa är inte skadliga handlingar, men de är ett misslyckande att följa standardpraxis, och de skapar en exponering du inte har bett om. För mer om detta ämne, se vår översikt över säkerhet i Claude-skills.

Den konstruktiva sidan: Skills som förbättrar säkerheten

Skill-ekosystemet är inte bara en källa till potentiell risk; det är också en källa till kraftfulla verktyg för att mildra den. Samma ramverk som låter en skill interagera med ditt filsystem låter också en skill granska det för sårbarheter. Vi har testat flera skills som är utformade specifikt för säkerhetsgranskningar.

Skill Security Auditor är ett utmärkt exempel. Vi testade den mot en 13-raders fil som innehöll uppenbar SQL-injektion, kommandoinjektion och en hårdkodad API-nyckel. Dess analysskript identifierade framgångsrikt alla tre sårbarheterna. Som en bonus flaggade den också för en saknad .gitignore-fil, ett problem som en mänsklig granskare hade missat.

På liknande sätt körde vi Code Health Check mot det medvetet buggiga Express API som skillen levererar i sitt eget repository. Den hittade alla åtta planterade problemen, vilka inkluderade SQL-injektion, en eval()-baserad konfigurationsparser, två hårdkodade hemligheter, ett ignorerat fel ('swallowed error') och en död funktion. Den gav korrekta allvarlighetsgrader och exakta fil- och radnummerhänvisningar för varje.

Dessa verktyg demonstrerar den andra sidan av skill-kapabiliteter. Genom att ge en betrodd gransknings-skill kontrollerad åtkomst till din kod kan du automatisera delar av din säkerhetsgranskningsprocess. Du kan hitta fler verktyg som detta i vår guide till Claude-skills för säkerhetsgranskning.

Hur du skyddar dig: En praktisk hotmodell

Givet att det primära hotet är överdriven behörighetstilldelning snarare än skadlig kod, förändras försvarsstrategin. Det handlar mindre om antivirus och mer om operativ disciplin.

1. Anta god avsikt, verifiera omfattning: Utvecklaren av skillen du installerar försöker förmodligen inte hacka dig. Men de kan ha varit slarviga eller prioriterat bekvämlighet över säkerhet. När en skill ber om behörigheter, läs uppmaningen. Om den ber om skrivåtkomst till hela din hemkatalog för att lägga till en rad i en enda konfigurationsfil, neka.

2. Föredra skills med litet påverkansområde ('blast radius'): Leta efter skills som är fristående och följer principen om minsta privilegium. Ett utmärkt exempel på detta är Workthreads. Det är en fristående skill utan några beroenden. Den anropar endast git via execFileSync med fasta array-argument för att förhindra kommandoinjektion, och den levereras med inbyggd, deterministisk maskering av hemligheter för AWS, GitHub, Slack, OpenAI, Anthropic, JWTs och bearer-tokens innan den skriver ut någon output. Den var uppenbarligen byggd med ett litet, kontrollerat påverkansområde i åtanke.

3. Kör i en sandlåda: Kör inte en ny, okänd skill på din primära produktionskodbas eller från din hemkatalog. Skapa en dedikerad, temporär katalog för testning. Använd Docker eller andra container-tekniker för en ännu starkare gräns.

4. Lita på exekvering, inte bara kod: Det enda sättet att vara säker på vad en skill gör är att köra den och observera dess beteende. Detta är den grundläggande principen i SkillProofs metodik. Vi publicerar våra testanteckningar, inklusive säkerhetsvarningar som de fem i denna artikel, för varje skill vi kör.

Relaterad läsning: den praktiska uppföljningen till denna artikel är hur en skills allowed-tools-deklaration faktiskt begränsar vad den kan röra, vilket är den spak de flesta av problemen ovan handlar om. För hur det bredare ekosystemet av listningar beskriver sig självt kontra vad det verifierar, se vår verklighetskontroll av register.

Varje säkerhetsvarning som citeras här är offentlig på skillens egen katalogsida, tillsammans med dess utlåtande och poäng, så att du kan läsa bevisen innan du installerar något. Om du hellre vill börja med en uppsättning som redan har gått igenom detta, samlar vårt Security & Code Review Pack tio testade skills för kodgranskning, felsökning och kontraktstestning.