Plugin4Shell è una vulnerabilità zero-click negli agenti di coding AI. Permette a chi controlla il repository di un plugin di sostituire il codice approvato dal marketplace con un altro. Il codice arriva sulla tua macchina senza che tu clicchi o confermi niente. Colpisce i quattro agenti più usati: Claude Code, Codex, GitHub Copilot e Gemini CLI. L'ha resa pubblica il 17 settembre 2026 il laboratorio di ricerca di AIR Security.
Uso Claude Code ogni giorno e ho un server MCP mio collegato ai miei progetti. Quando ho letto di Plugin4Shell, la prima cosa che ho fatto è stata aprire il terminale e controllare la versione. In questo articolo ti spiego come funziona l'attacco in termini pratici, chi ha già la patch e chi no, e i controlli che ho fatto io e che ti consiglio di fare oggi stesso.
Cos'è Plugin4Shell in due righe
I marketplace di plugin sono i cataloghi da cui Claude Code, Codex e gli altri scaricano estensioni e skill. Si difendono con il pinning SHA: ogni plugin viene fissato a un commit preciso, identificato dall'hash di 40 caratteri esadecimali che Git assegna a ogni versione.
Il marketplace revisiona quella versione. L'agente dovrebbe installare solo quella, mai il ramo più recente del repository, che l'autore può cambiare quando vuole.
Plugin4Shell dimostra che il pin è una promessa non mantenuta. L'agente fa il checkout dell'hash fissato ma non verifica mai che il codice finito su disco sia davvero quello. Un controllo di una riga, dimenticato da tutti e quattro i fornitori.
Come funziona l'attacco Plugin4Shell, passo per passo
Il trucco sta in una regola di Git poco nota. Un ramo può chiamarsi con un nome di 40 caratteri esadecimali, identico a un hash. Quando un nome può essere letto sia come riferimento (ramo) sia come commit, Git dà la precedenza al riferimento e stampa solo un avviso di ambiguità. Plugin4Shell sfrutta esattamente questo.
La sequenza completa
- Pubblicazione: l'attaccante pubblica un plugin davvero innocuo su un marketplace, supera la revisione e ottiene uno SHA fissato.
- Adozione: gli utenti lo installano, la versione con quell'hash gira senza problemi.
- Aggiornamento pulito: con una release di routine, ancora innocua, il marketplace passa a un nuovo hash.
- Rug-pull: l'attaccante crea nel proprio repository un ramo che si chiama esattamente come il nuovo hash. Ci mette il codice malevolo e lo imposta come ramo predefinito.
- Esecuzione: al primo aggiornamento automatico l'agente fa clone e checkout. Git risolve il nome sul ramo invece che sul commit, e il codice malevolo gira. L'agente riporta un'installazione riuscita al commit fissato.
Questo è quello che l'agente esegue, e il controllo che mancava:
# cosa fa l'agente all'installazione e a ogni aggiornamento in background
git clone https://esempio.org/plugin.git plugin
git -C plugin checkout 4f9c2b7e1a8d3c6b5e0f9a2d7c1b8e4f3a6d9c02
# cosa prepara l'attaccante nel proprio repository
git branch 4f9c2b7e1a8d3c6b5e0f9a2d7c1b8e4f3a6d9c02
# poi lo imposta come ramo predefinito
# il controllo che mancava: dopo il checkout HEAD deve coincidere con il pin
test "$(git rev-parse HEAD)" = "<sha-fissato>" || exit 1
La variante di Gemini CLI
Gemini CLI segue un percorso diverso: un git fetch origin <sha> seguito da git checkout FETCH_HEAD. Qui il trucco cambia nome. Se il ramo predefinito del repository si chiama proprio FETCH_HEAD, il checkout finisce su quello invece che sul commit appena scaricato. Cambia il dettaglio, l'errore di fondo è lo stesso: nessuno confronta l'HEAD risultante con l'hash atteso.
Perché Plugin4Shell è zero-click e perché conta
A trasformare un difetto di Git in una falla zero-click è l'aggiornamento automatico dei plugin. Claude Code e Codex aggiornano in background i plugin già installati per impostazione predefinita. Quando il marketplace sposta il pin, il checkout riparte da solo. Nessuna nuova installazione, nessuna richiesta di conferma, niente da notare.
Quanto vale il colpo dipende da cosa può toccare un plugin. Di norma eredita i permessi dello sviluppatore che usa l'agente: codice sorgente locale, credenziali cloud, chiavi SSH, repository interni, variabili d'ambiente con le API key.
Un'esecuzione di codice remoto su quella macchina equivale a consegnare una postazione di lavoro completa. È lo stesso schema che ho descritto analizzando il threat report di Anthropic sulle API key rubate: l'agente è il punto in cui si concentrano tutti i segreti.
Le condizioni che devono verificarsi
Plugin4Shell non colpisce chiunque abbia Claude Code installato. Servono tre condizioni insieme:
- Un plugin di terzi già installato da un marketplace.
- Un attaccante che controlla il repository di quel plugin, perché lo ha scritto lui o perché lo ha dirottato. I dirottamenti di repository esistono e sono già stati dimostrati su larga scala.
- Un hosting che accetta rami con nomi da hash. GitHub li blocca; Bitbucket e i server Git self-hosted li accettano. E Anthropic documenta Bitbucket e Git self-hosted come backend validi per i marketplace.
Non risultano sfruttamenti di Plugin4Shell in attacchi reali. AIR ha dimostrato la tecnica su tutti e quattro gli agenti a maggio 2026, in laboratorio.
Plugin4Shell: chi ha la patch e chi no (al 22 settembre 2026)
| Agente | Stato | Versione corretta |
|---|---|---|
| Claude Code (Anthropic) | Corretto | 2.1.179 o successive (fix confermato il 17 giugno) |
| Codex (OpenAI) | Corretto | 0.146.0 o successive (verificato il 12 agosto) |
| GitHub Copilot (Microsoft) | Nessuna patch | Nessuna. GitHub cita il blocco dei nomi simili a SHA sul proprio servizio |
| Gemini CLI (Google) | Ritirato, non corretto | Nessuna. Google indirizza ad Antigravity CLI |
La cronologia è la parte rassicurante. AIR ha trovato il difetto a maggio e ha avvisato i quattro fornitori a giugno. Le due correzioni sono arrivate mesi prima della divulgazione pubblica. Vale però solo per chi ha aggiornato nel frattempo: se hai Claude Code installato da mesi e non lo aggiorni mai, sei ancora esposto a Plugin4Shell.
Microsoft è il nodo scomodo. GitHub sostiene che il servizio non consente rami con nomi simili a uno SHA, quindi gli attacchi non lo riguardano. Ma i marketplace di Copilot possono vivere anche su Bitbucket. E soprattutto il pin viene risolto sul computer dell'utente.
Nessun marketplace può chiudere Plugin4Shell da solo: la correzione deve stare nell'agente. La risposta di GitHub descrive una difesa parziale, non una patch.
I controlli che ho fatto io contro Plugin4Shell (e che ti consiglio)
Questa è la parte pratica. Sono cinque passaggi, i primi due richiedono meno di un minuto.
1. Controlla la versione dell'agente
claude --version # deve essere >= 2.1.179
codex --version # deve essere >= 0.146.0
Se il numero è più basso, aggiorna subito. Io tengo Claude Code aggiornato perché seguo le release per lavoro. Conosco però sviluppatori che lo hanno installato una volta e non lo hanno più toccato: quello è il caso a rischio.
2. Elenca i plugin di terzi e la loro provenienza
Fai l'inventario di cosa hai installato e da dove arriva. Su Copilot e Gemini CLI non c'è nessuna correzione per Plugin4Shell, quindi la provenienza è l'unica difesa. Tieni i plugin che arrivano da marketplace ospitati su GitHub. Guarda con sospetto quelli su Bitbucket o su server Git che non gestisci tu.
Vale lo stesso ragionamento che faccio quando scelgo quali skill installare davvero su Claude Code: meno estensioni, da autori che conosco.
3. Spegni l'aggiornamento automatico dei plugin di terzi
Dove l'agente lo consente, disattiva l'auto-update dei plugin finché non conosci l'hash di ciò che hai installato. È la mossa che toglie a Plugin4Shell il carattere zero-click. Se l'aggiornamento è manuale, torni a essere tu a decidere quando far girare codice nuovo.
4. Se gestisci un marketplace interno, aggiungi il controllo
Dopo il checkout confronta lo SHA di HEAD con quello fissato e blocca l'installazione se sono diversi. È l'ultima riga del riquadro qui sopra. Deve controllare l'HEAD risolto, non il riferimento richiesto: è proprio quella distinzione che la variante di Gemini CLI sfrutta.
5. Esci da Gemini CLI
Google lo ha ritirato e non lo correggerà. Se lo hai ancora installato, la strada indicata dalla stessa Google è Antigravity CLI. Non ha un pinning SHA da aggirare e quindi non è toccato da Plugin4Shell.
Il terzo capitolo di una serie
Plugin4Shell è il terzo studio di AIR sulla catena di fornitura degli agenti. Il primo mostrava una skill malevola arrivata a 26.000 agenti passando per un marketplace di fiducia. Il secondo, SkillJacking, era un dirottamento di repository che toccava 925 skill e 134.000 agenti. Il pinning SHA era la contromisura pensata proprio per quegli scenari. Questa ricerca la aggira.
È un pattern che vedo ripetersi da mesi e di cui ho già scritto: il worm Shai-Hulud che entra dai coding assistant e l'HalluSquatting che sfrutta le allucinazioni degli agenti per fargli installare pacchetti inventati.
Il denominatore comune è semplice. L'agente esegue codice di terzi con i tuoi permessi, e ogni anello della catena (registro npm, repository, marketplace) è un punto in cui qualcuno può inserirsi.
Una nota di onestà sulla fonte. AIR vende protezione per i plugin degli agenti in azienda e nella ricerca scrive che i propri clienti non erano esposti. Lo studio è anche una vetrina commerciale. Il meccanismo però si riproduce con Git in pochi minuti, quindi il conflitto d'interessi non ne toglie credibilità.
Quello che invece non torna è il titolo che parla di "milioni di agenti coinvolti": nella ricerca su Plugin4Shell non c'è un conteggio a sostegno di quel numero.
Cosa cambia nel modo in cui uso gli agenti
Il pinning SHA prometteva una cosa semplice: quello che è stato approvato è quello che gira. Tutti e quattro gli agenti hanno saltato lo stesso controllo. Questo dice che il difetto dietro Plugin4Shell sta nel modo in cui il settore ha costruito il sistema dei plugin, non nell'errore di un singolo fornitore. Anthropic e OpenAI hanno chiuso in tempi rispettabili, Microsoft ha indicato una difesa che vale solo su GitHub, Google ha spento il prodotto.
Per me la lezione è che l'ecosistema dei plugin va trattato come un registro di pacchetti qualsiasi: niente installazioni per curiosità, inventario di ciò che c'è, aggiornamenti che decido io.
Vuoi capire come organizzo il lavoro con Claude Code senza affidarmi a estensioni di terzi? Ho raccolto quello che ho imparato nell'articolo sulle best practice emerse da 400.000 sessioni e in quello sui thread paralleli di Claude Code Projects.
Se usi agenti AI in azienda e vuoi una mano a verificare cosa gira sulle macchine del tuo team, scrivimi. Rispondo io, e un controllo su plugin installati e provenienza si fa in una mattinata.



