Dopo aver eseguito 1.672 skill di Claude, il vero rischio per la sicurezza non è il malware

Quando si tratta di strumenti per sviluppatori come le skill di Claude, il timore per la sicurezza si traduce nella ricerca di malware classici: furti di credenziali nascosti, comandi shell offuscati e altri payload occulti. Questo timore è fondato. L'audit ToxicSkills di Snyk ha analizzato 3.984 skill da ClawHub e skills.sh al 5 febbraio 2026, rilevando pattern di prompt-injection nel 36% dell'ecosistema, 534 skill con problemi di sicurezza critici e 76 payload malevoli confermati da una revisione umana, di cui 8 ancora attivi su clawhub.ai al momento della pubblicazione. L'incidente parallelo ClawHavoc ha visto la rimozione di 341 skill malevole dal registro di ClawHub. Le skill di agenti malevoli non sono un'ipotesi.

È quindi importante essere precisi su ciò che abbiamo trovato e su cosa il nostro numero significhi e non significhi. In SkillProof installiamo ed eseguiamo ogni skill che elenchiamo, per poi pubblicarne il risultato, positivo o negativo. Al momento della stesura di questo articolo, abbiamo testato 1.672 skill: 1045 hanno superato il test (un tasso di successo del 63%), 560 richiedono una configurazione manuale e 67 hanno ottenuto un punteggio inferiore a Claude senza alcuna skill installata. Non siamo a conoscenza di altre directory che pubblichino i verdetti negativi insieme a quelli positivi.

In questi 1.672 test eseguiti, non abbiamo trovato alcuna istanza di malware occulto. Questo risultato va preso con le pinze: il nostro catalogo non è un campione casuale di un registro pubblico. I candidati vengono pre-selezionati per la qualità prima ancora di arrivare a un test, i repository di bassa qualità e spam sono tenuti in una block list, e le skill che sopravvivono fino a un verdetto pubblicato sono quelle che hanno già buone probabilità di essere legittime. Snyk ha campionato il registro; noi campioniamo la parte che vale la pena installare. Entrambi i numeri sono veri e rispondono a domande diverse.

Ciò a cui il nostro campione risponde è la domanda che nessun altro si pone: una volta filtrato il malware evidente, di cosa resta da preoccuparsi? La risposta, in modo riproducibile, è il 'blast radius' dei permessi e delle capacità di skill legittime e utili. Questo rischio è più difficile da rilevare con una scansione, perché risiede principalmente in ciò che una skill chiede di approvare al momento dell'installazione e dell'esecuzione.

Cosa non abbiamo trovato: l'assenza di payload occulti

Siamo diretti. In oltre milleseicento esecuzioni di skill uniche, abbiamo trovato:

• Zero istanze di esfiltrazione occulta di credenziali verso un server sconosciuto.
• Zero istanze di un payload curl | sh nascosto nei file di una skill. Diverse skill includono un installer curl | bash nel README del loro repository e, in un caso, l'installazione della CLI di terze parti non è menzionata affatto nel file SKILL.md. Si tratta di passaggi di installazione dichiarati che si possono leggere prima dell'esecuzione, non di payload nascosti, ma vale la pena notarli.
• Zero istanze di payload offuscati in base64 o altre tecniche di offuscamento classiche progettate per nascondere l'intento.
• Zero istruzioni nascoste in un file SKILL.md che differivano dallo scopo pubblico della skill.

La ricerca di esempi concreti di malware nel nostro set di test non ha prodotto risultati. Ciò non significa che la scansione sia inutile. Significa che gli scanner più comuni sono sintonizzati sulle firme sbagliate. Uno strumento che cerca pattern di codice malevolo non restituisce nulla sul nostro campione; uno strumento sintonizzato su pattern di permessi e capacità intercetterebbe la maggior parte di ciò che abbiamo registrato, perché tali pattern sono presenti nel testo del file. La differenza sta in cosa si cerca, non se la ricerca funzioni. L'esecuzione rileva comunque ciò che nessuno dei due metodi trova: quali permessi una skill richiede effettivamente quando la si esegue e cosa scrive nella configurazione una volta dato il consenso. Per un'analisi più approfondita del nostro processo, vedi come testiamo le skill di Claude.

La vera minaccia: il 'blast radius' dei permessi nelle skill legittime

I problemi di sicurezza più significativi che abbiamo riscontrato riguardavano skill altrimenti funzionali e di valore. Due delle cinque skill seguenti superano i nostri test di funzionalità; le altre tre richiedono una configurazione manuale. Nessuna di esse è malevola. Il pericolo che introducono non è la malizia, ma una capacità eccessiva. Il loro 'blast radius' — l'ambito di ciò che possono fare con i permessi concessi — è inutilmente ampio. Non si tratta necessariamente di skill di Claude pericolose da evitare a priori, ma richiedono una gestione attenta e la comprensione dei permessi che si concedono.

Accesso eccessivamente ampio al file system

Un pattern comune è la richiesta di permessi del file system ben oltre quelli necessari al funzionamento della skill. Un ottimo esempio è UCTM Init, un inizializzatore di progetto per la pipeline di plugin uc-taskmanager. Durante la configurazione, presenta un prompt generico per applicare le "impostazioni consigliate", che include la scrittura di ampi permessi Read/Edit/Write(/**) nel file di configurazione locale .claude/settings.local.json. Nella nostra esecuzione su un progetto di prova, quella singola approvazione ha fatto due cose distinte: ha scritto le voci wildcard di lettura/modifica/scrittura, che costituiscono il vero 'blast radius' sul file system, e ha unito 34 permessi Bash nominati nella configurazione del progetto. Le voci Bash nominate sono una allowlist di comandi enumerati e rappresentano la metà più difendibile; la wildcard è la parte da leggere prima di cliccare 'sì'. La skill funziona e supera i nostri test, ma l'ambito che si sta approvando è molto più ampio del compito da svolgere.

Token API perpetui e senza ambito

Un altro problema ricorrente è la gestione delle chiavi API. La skill Add Vercel, che collega le credenziali di deploy di Vercel ai container degli agenti NanoClaw, istruisce l'utente a creare un token API di Vercel con ambito "Full Account" e senza data di scadenza. Assegna quindi questo potente token a ogni agente. Un agente compromesso o difettoso potrebbe, in teoria, usare questo token per leggere, modificare o eliminare qualsiasi progetto, team o configurazione all'interno dell'intero account Vercel. La soluzione è semplice — creare un token con ambito ristretto e ruotarlo — ma il percorso predefinito crea un rischio significativo.

Il 'footgun' di --dangerously-skip-permissions

Claude Code include un flag, --dangerously-skip-permissions, che salta i prompt di conferma interattivi per un'esecuzione; la stessa documentazione di Anthropic consiglia di limitarne l'uso a un container o a una VM. È una funzionalità nota per utenti esperti, ma abbiamo trovato diverse skill che ne normalizzano l'uso, integrandola in comandi predefiniti o configurazioni persistenti. Una sessione interattiva mostra una finestra di dialogo di accettazione una tantum la prima volta che si entra in quella modalità, che è precisamente ciò che un'impostazione di configurazione persistente elude. Il risultato trasforma un override deliberato per singola esecuzione in uno stato invisibile e permanente di sicurezza ridotta.

Skill	Contesto d'uso del flag	Rischio
OMA Image	Comando predefinito del sub-agente CLI	Un processo figlio viene eseguito senza controlli sui permessi.
Agentic OS Obsidian	Configurazioni persistenti di dashboard/terminale	Trigger non presidiati si attivano senza conferma per singola esecuzione.
Agy CLI	Pattern raccomandato per esecuzioni delegate	Normalizza la disattivazione di una funzionalità di sicurezza fondamentale per l'uso di routine.

Nel caso di OMA Image, il comando canonico per il suo sub-agente include il flag per impostazione predefinita. Per Agentic OS Obsidian, il flag è integrato nelle configurazioni persistenti per i pulsanti della dashboard e i profili del terminale, il che significa che le azioni possono essere attivate senza ulteriori prompt di sicurezza. Agy CLI lo raccomanda come pattern standard per le esecuzioni delegate. Sebbene la documentazione della skill segnali il rischio, il suo pattern di utilizzo comune disabilita di fatto un meccanismo di sicurezza critico. Ancora una volta, si tratta di strumenti utili, ma le loro configurazioni predefinite barattano la sicurezza con la comodità in un modo che merita cautela.

Rischi secondari: gestione dei dati e astrazioni 'leaky'

Oltre alle concessioni esplicite di permessi, abbiamo anche osservato pratiche di sicurezza scadenti che aumentano la superficie di attacco di un sistema o espongono informazioni sensibili, anche se non costituiscono malware attivo.

Un esempio è AI Search Hub. Il suo script wrapper funziona copiando l'intera directory dei dati utente del browser — inclusi cookie e sessioni attive — in una cartella di profilo locale, ignorata da git (chrome_debug_profile_skill). Espone anche il Chrome DevTools Protocol sulla porta 9222 della macchina locale. Non si tratta di esfiltrazione; i dati non lasciano la macchina locale. Tuttavia, crea una copia locale di dati di sessione sensibili e apre una potente porta di debug, espandendo il 'blast radius' per qualsiasi altro processo locale che potrebbe essere compromesso.

Un altro esempio è Google Ad Scraper. Questa skill passa il suo token API come parametro di query nell'URL (?token=...) anziché in un header Authorization. Le query string sono il posto peggiore dove mettere un segreto: finiscono nella cronologia della shell, nei log di accesso del server e in qualsiasi proxy lungo il percorso. La stessa skill invia anche quel token a un endpoint di terze parti, api.gooseworks.ai, quando viene impostata una chiave corrispondente. Questi non sono atti malevoli, ma una mancata adozione delle pratiche standard, e creano un'esposizione non richiesta. Per maggiori informazioni su questo argomento, consulta la nostra panoramica sulla sicurezza delle skill di Claude.

Il lato costruttivo: skill che migliorano la sicurezza

L'ecosistema delle skill non è solo una fonte di rischio potenziale; è anche una fonte di potenti strumenti per mitigarlo. Lo stesso framework che permette a una skill di interagire con il tuo file system permette anche a una skill di analizzarlo alla ricerca di vulnerabilità. Abbiamo testato diverse skill progettate specificamente per le revisioni di sicurezza.

Skill Security Auditor è un esempio eccellente. L'abbiamo testato su un file di 13 righe contenente evidenti SQL injection, command injection e una chiave API hardcoded. I suoi script di analisi hanno identificato con successo tutte e tre le vulnerabilità. Come bonus, ha anche segnalato un file .gitignore mancante, un problema che era sfuggito a un revisore umano.

Allo stesso modo, abbiamo eseguito Code Health Check contro l'API Express deliberatamente difettosa che la skill fornisce nel proprio repository. Ha trovato tutti gli otto problemi inseriti, che includevano SQL injection, un parser di configurazione basato su eval(), due segreti hardcoded, un errore ignorato e una funzione morta. Ha fornito livelli di gravità corretti e citazioni precise di file e numero di riga fornite per ciascuno.

Questi strumenti dimostrano l'altro lato della medaglia delle capacità delle skill. Concedendo a una skill di auditing fidata un accesso controllato al tuo codice, puoi automatizzare parti del tuo processo di revisione della sicurezza. Puoi trovare altri strumenti come questo nella nostra guida alle skill di Claude per la revisione della sicurezza.

Come proteggersi: un modello di minaccia pratico

Dato che la minaccia principale è l'eccesso di permessi piuttosto che il malware, la strategia difensiva cambia. È meno una questione di antivirus e più di disciplina operativa.

1. Presumi buone intenzioni, verifica l'ambito: Lo sviluppatore della skill che stai installando probabilmente non sta cercando di hackerarti. Ma potrebbe essere stato negligente o aver dato priorità alla comodità rispetto alla sicurezza. Quando una skill chiede dei permessi, leggi il prompt. Se chiede l'accesso in scrittura a tutta la tua home directory per aggiungere una riga a un singolo file di configurazione, nega il permesso.

2. Prediligi skill con un 'blast radius' ridotto: Cerca skill che siano autonome e seguano il principio del privilegio minimo. Un ottimo esempio è Workthreads. È una skill autonoma con zero dipendenze. Chiama git solo tramite execFileSync con argomenti array fissi per prevenire la command injection, e include una redazione dei segreti integrata e deterministica per AWS, GitHub, Slack, OpenAI, Anthropic, JWT e bearer token prima di stampare qualsiasi output. È stata chiaramente costruita pensando a un 'blast radius' piccolo e controllato.

3. Esegui in una sandbox: Non eseguire una skill nuova e sconosciuta sulla tua codebase di produzione principale o dalla tua home directory. Crea una directory dedicata e usa e getta per i test. Usa Docker o altre tecnologie di containerizzazione per un isolamento ancora più forte.

4. Fidati dell'esecuzione, non solo del codice: L'unico modo per essere certi di ciò che fa una skill è eseguirla e osservarne il comportamento. Questo è il principio fondamentale della metodologia di SkillProof. Pubblichiamo le nostre note di test, inclusi gli avvisi di sicurezza come i cinque di questo articolo, per ogni skill che eseguiamo.

Letture correlate: il seguito pratico di questo articolo è come la dichiarazione allowed-tools di una skill ne delimita l'ambito d'azione, che è la leva su cui si basano la maggior parte dei problemi sopra descritti. Per un confronto tra come l'ecosistema di directory più ampio si descrive e ciò che verifica, vedi il nostro reality check sulle directory.

Ogni avviso di sicurezza citato qui è pubblico sulla pagina di catalogo della skill, insieme al suo verdetto e punteggio, così puoi leggere le prove prima di installare qualsiasi cosa. Se preferisci partire da un set che ha già superato questo processo, il nostro Security & Code Review Pack raccoglie dieci skill testate per la revisione del codice, il debugging e il contract testing.