Plugin4Shell rompe il pin degli agenti di codice e due fornitori su quattro restano scoperti

Il 17 settembre il laboratorio di ricerca di AIR, società di sicurezza per agenti aziendali uscita dallo stealth il primo settembre, ha pubblicato Plugin4Shell: una falla di esecuzione di codice da remoto che riguarda insieme Claude Code, OpenAI Codex, GitHub Copilot e Gemini CLI. La cronologia dichiarata è ordinata: scoperta a maggio 2026 con exploit funzionanti contro tutti e quattro gli agenti, divulgazione coordinata ai fornitori a giugno, pubblicazione a settembre, quando due di loro avevano rilasciato la correzione e due avevano scelto altre strade.

La fiducia in una catena di fornitura si misura sul controllo che qualcuno esegue per ultimo.

L’aspetto che rende la vicenda interessante sta un livello sopra il bug. Le ricerche sulla sicurezza degli agenti hanno finora guardato al modello e all’agente; qui il bersaglio è lo strato di distribuzione sottostante, cioè i marketplace attraverso cui le estensioni raggiungono milioni di macchine. È la prima falla di supply chain dell’ecosistema degli agenti, ed è arrivata con la stessa forma che il software libero conosce da vent’anni: una dipendenza fidata che cambia contenuto restando uguale di nome.

Il pin si scrive, la verifica si ferma un passo prima

Un marketplace di plugin funziona per approssimazione così: il codice di un’estensione passa una revisione, il marketplace registra l’hash del commit revisionato, e da quel momento ogni installazione dichiara di riferirsi a quel commit preciso. È la logica del lockfile nei gestori di pacchetti. La revisione vale per una versione, e quella versione è quella che gira.

I quattro agenti eseguono il checkout del commit indicato dal pin e considerano concluso il lavoro. Il controllo che manca è l’ultimo: rileggere quale commit è davvero atterrato nella working tree e fermarsi appena il risultato diverge dal pin. Una riga sola lo chiude, e vale per entrambe le varianti:

test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort

Su Claude Code, Codex e Copilot la leva è il modo in cui git risolve i nomi. Chi controlla il repository del plugin crea un branch il cui nome coincide con i 40 caratteri esadecimali del commit pinnato e lo imposta come branch di default. Al git checkout aaaa… git trova un nome che è insieme riferimento valido e identificativo di oggetto, e dà la precedenza al riferimento: emette un avviso di ambiguità e prosegue. Sul disco finisce il contenuto del branch, mentre l’agente registra un’installazione riuscita sul commit atteso.

Gemini CLI arriva allo stesso esito per un’altra strada. L’installazione scarica il commit corretto con git fetch e poi esegue git checkout FETCH_HEAD: quando il branch di default del repository si chiama a sua volta FETCH_HEAD, il checkout risolve il nome sul branch e il commit appena scaricato resta da parte. Il controllo da eseguire, osservano i ricercatori, riguarda HEAD dopo il checkout e lascia fuori il riferimento richiesto: è proprio quella distinzione che la variante Gemini attraversa.

L’aggiornamento in background porta il conto a zero clic

La parte che allarga il perimetro è l’aggiornamento automatico. Gli agenti aggiornano in background i plugin già installati, e su Claude Code e Codex questo comportamento è il default. Quando il marketplace sposta il pin su una nuova versione, lo stesso git checkout si ripete su ogni macchina che ha quel plugin: la sostituzione raggiunge installazioni esistenti in assenza di un passaggio di installazione, di un prompt, di qualcosa da notare.

Ne deriva la conseguenza più scomoda per chi governa il rischio: la vittima tipo ha fatto tutto correttamente. Le organizzazioni che vanno oltre il marketplace di comunità, revisionano il codice e lo pinnano su un commit verificato, poggiano proprio sul pin la garanzia che quel codice resti quello. Plugin4Shell annulla la garanzia in silenzio, e ogni processo di vetting costruito sopra il pin eredita la falla.

AIR indica due percorsi di sfruttamento, entrambi già dimostrati sul campo dallo stesso gruppo in ricerche precedenti. Il primo pubblica un plugin genuinamente utile, supera la revisione, raccoglie installazioni e cambia contenuto dopo: un esperimento del laboratorio ha raggiunto oltre 26.000 agenti con una skill costruita per l’occasione. Il secondo prende il controllo del repository dietro un plugin scritto da altri e già adottato: la ricerca che il gruppo chiama SkillJacking ha contato 925 skill in uso passate di mano dai manutentori originali, con 134.000 agenti coinvolti.

Il nome di branch funziona dove l’host lo consente

La variante principale richiede una condizione precisa: che l’host git accetti un branch chiamato come un hash. GitHub rifiuta in partenza i nomi di 40 caratteri esadecimali. Bitbucket li accetta, e li accetta qualunque server git installato in proprio, perché il comportamento nativo di git accetta quei nomi. La documentazione di Anthropic elenca Bitbucket e i server git self-hosted fra i backend validi per un marketplace, quindi la configurazione vulnerabile resta una configurazione supportata.

È il punto che tocca da vicino il mercato italiano. Banche, utility, assicurazioni, sanità e amministrazioni pubbliche tengono il codice su GitLab o Bitbucket installati in casa, per ragioni di sovranità del dato, di audit e di continuità con l’infrastruttura esistente. Quella scelta, motivata da tutt’altro, coincide con l’ambiente in cui la variante del nome di branch funziona. Il parametro di rischio, insomma, sta in un dettaglio di piattaforma che raramente compare nelle valutazioni di sicurezza degli strumenti di sviluppo.

Quattro fornitori, quattro risposte

Anthropic ha confermato la correzione il 17 giugno in Claude Code 2.1.179. OpenAI ha corretto Codex nella versione 0.146.0, verificata il 12 agosto. Il 4 agosto Google ha comunicato che una correzione resta fuori programma, perché Gemini CLI è in deprecazione: agli utenti indica la migrazione verso Antigravity, che adotta un modello di distribuzione privo del pin da aggirare. Microsoft, informata della stessa falla su Copilot, alla data della pubblicazione lascia i propri utenti in attesa di una patch.

La divergenza è istruttiva quanto il bug. Lo stesso errore di progettazione compare in quattro prodotti costruiti da quattro laboratori diversi, il che suggerisce un difetto di modello condiviso più che una svista di implementazione. E poiché il pin viene risolto dentro il client, il marketplace resta spettatore: può limitare i danni ammettendo soltanto host che rifiutano nomi a forma di hash, cioè in pratica GitHub, al prezzo di escludere backend che gli agenti stessi dichiarano supportati, e la variante Gemini resta comunque fuori portata.

Un elemento di contesto va tenuto presente nella lettura. AIR vende un prodotto in questo mercato e nell’articolo segnala che i clienti del proprio marketplace e del proprio filtro restano fuori dal perimetro colpito. La descrizione tecnica resta verificabile riga per riga da chiunque disponga di un repository di prova, le versioni correttive sono pubbliche e riscontrabili, i numeri delle ricerche precedenti arrivano dalla stessa fonte. Chi valuta tiene distinte le tre cose.

La dipendenza che sfugge all’inventario

La lezione utile supera il singolo bug. Un plugin di agente è codice di terze parti che entra su una macchina di sviluppo ed eredita i permessi di chi la usa: accessi ai repository aziendali, token in memoria, credenziali di ambiente, connessioni ai sistemi interni. Nell’inventario delle dipendenze, però, quel codice compare di rado. Le distinte dei componenti software coprono le librerie del prodotto; il registro dei fornitori ICT che DORA impone agli operatori finanziari copre i contratti; gli obblighi di gestione della catena di fornitura introdotti da NIS2 coprono i fornitori diretti. Un’estensione scaricata da un marketplace di comunità e aggiornata in background attraversa tutte e tre le maglie.

Il mercato si sta muovendo su questo fronte: questa sala stampa ha registrato il 2 settembre l’introduzione della scansione automatica di skill e plugin di terze parti nei piani Enterprise di Claude, e il 27 agosto lo stesso laboratorio di AIR aveva documentato 155 server MCP dirottabili nel marketplace ufficiale. Sono risposte parziali a un problema che ha la forma di un registro mancante più che di una vulnerabilità singola.

Cosa fare adesso

Le mosse utili qui valgono a prescindere dal fornitore scelto, e la maggior parte si esegue in una settimana.

Inventario, prima di tutto. Quali agenti di codice girano sulle macchine di sviluppo, in quale versione, con quali plugin installati e da quale marketplace. La domanda sembra banale e in molte organizzazioni la risposta oggi arriva per sentito dire.
Alzare la versione minima. Claude Code a 2.1.179 o successiva, Codex a 0.146.0 o successiva. Dove la patch resta attesa, come su Copilot, o esclusa, come su Gemini CLI, la decisione riguarda il controllo compensativo: sospendere l’uso dei marketplace di plugin, isolare l’agente in un ambiente dedicato, oppure pianificare la migrazione.
Guardare l’host del marketplace. Chi ospita i repository dei plugin su un server proprio o su Bitbucket si trova nella configurazione in cui la variante principale funziona. Vale la pena scrivere il vincolo nella policy interna, prima che nel piano di rimedio.
Trattare l’auto-update come un cambio di versione. Un aggiornamento che porta codice nuovo su una macchina aziendale merita una traccia: almeno un log di quali versioni di plugin atterrano dove, meglio se una finestra di approvazione.
Chiedere l’asserzione ai fornitori, per iscritto. La domanda giusta da mettere nel questionario di sicurezza è precisa: dopo il checkout, l’agente rilegge il commit effettivo e interrompe l’installazione quando diverge dal pin?
Portare le macchine di sviluppo dentro la mappa che esiste già. Chi ha completato la mappatura della catena di fornitura per NIS2 o il registro dei fornitori ICT per DORA ha lo strumento pronto: basta estenderlo a una categoria di dipendenze che finora viveva fuori elenco.

La domanda che resta aperta riguarda il modello, più che il codice. Gli agenti hanno adottato in pochi mesi marketplace, plugin e aggiornamento automatico, cioè l’intero apparato di distribuzione che il software tradizionale ha costruito in vent’anni, e lo hanno fatto saltando la parte lenta: firme, registri pubblici, revoche, tempi di quarantena. La correzione di Plugin4Shell si scrive in una riga. Il registro di cosa gira davvero sulle macchine resta da costruire.

Autore

Pablo Liuzzi

Founder, Synthos Logic