Per bloccare un plugin a una versione revisionata, i marketplace degli agenti di coding usano il SHA pinning: si fissa l'hash del commit approvato e l'agente, in teoria, installa esattamente quel codice. I ricercatori di AIR Security hanno dimostrato che quel meccanismo non regge. La vulnerabilità, battezzata Plugin4Shell, permette a chi controlla il repository di un plugin di far installare codice arbitrario senza che l'utente clicchi, approvi o reinstalli nulla. Riguarda quattro agenti diffusi: Claude Code, OpenAI Codex, GitHub Copilot e Gemini CLI.

Il difetto: si chiede il commit, non si verifica dove si è atterrati

Il problema è concettualmente semplice, e proprio per questo insidioso. Tutti e quattro gli agenti chiedono a git il checkout del commit pinnato, ma nessuno verifica che l'albero di lavoro risultante corrisponda davvero a quel commit.

Per Claude Code, Codex e Copilot la leva è la risoluzione dei riferimenti di git: se nel repository esiste un branch il cui nome coincide con l'hash esadecimale a 40 caratteri, git può dare la precedenza al riferimento sull'oggetto commit. L'agente installa il contenuto del branch ostile e riporta un'installazione riuscita, perché il SHA atteso è formalmente quello richiesto. Gemini CLI è esposto attraverso una variante distinta: scarica il commit e poi esegue il checkout di FETCH_HEAD, e un branch chiamato proprio FETCH_HEAD dirotta l'operazione.

Il passaggio che trasforma un difetto di installazione in un attacco zero-click è l'aggiornamento automatico. Claude Code e Codex aggiornano i plugin installati in background per impostazione predefinita: quando il marketplace sposta il SHA pinnato, lo stesso git checkout viene rieseguito e il codice ostile raggiunge installazioni già presenti, senza alcuna azione dell'utente.

La condizione abilitante è che l'hosting consenta nomi di branch simili a un hash. GitHub rifiuta i nomi composti da 40 caratteri esadecimali, ma Bitbucket e qualunque server git self-hosted li accettano: i marketplace ospitati altrove restano quindi sfruttabili.

Due strade per arrivarci, entrambe già dimostrate

AIR indica due percorsi realistici. Nel primo l'attaccante pubblica un plugin che funziona davvero, supera la revisione, accumula installazioni e solo in un secondo momento lo rende ostile: la stessa società ha documentato in una ricerca precedente un plugin arrivato a oltre 26.000 agenti prima di essere rimosso. Nel secondo prende il controllo del repository di un plugin scritto da altri e già diffuso: nella ricerca che i ricercatori chiamano SkillJacking dichiarano di aver trovato 925 skill in uso attivo sottratte ai manutentori originali, con una portata di 134.000 agenti.

Il punto che merita attenzione è la platea colpita. Non sono gli utenti distratti: la vittima tipo ha installato un plugin da un marketplace affidabile, revisionato e pinnato esattamente come il modello di sicurezza prevede. Plugin4Shell colpisce proprio chi ha fatto tutto correttamente.

Cosa significa per le aziende italiane

Un agente di coding non è una libreria: è un processo che gira sulla postazione dello sviluppatore con i permessi dello sviluppatore. Codice sorgente proprietario, chiavi API, credenziali cloud, chiavi SSH, token della pipeline CI/CD, spesso accessi in lettura agli ambienti di collaudo e talvolta di produzione. Un plugin che esegue codice arbitrario in quel contesto ottiene lo stesso raggio d'azione dell'account che lo ospita, e lo ottiene passando da traffico git verso host legittimi, difficile da distinguere dal lavoro quotidiano di uno sviluppatore.

Nel tessuto italiano il rischio ha una forma specifica. Nelle software house e nelle PMI tecnologiche gli agenti di coding arrivano quasi sempre dal basso: li installa il singolo sviluppatore, spesso senza passare da un processo di approvazione, e i plugin li sceglie lui. Il risultato è che in molte aziende nessuno sa quali plugin siano installati su quali macchine, e senza quell'inventario la domanda «siamo esposti?» non ha una risposta. È il classico shadow IT, con l'aggravante che qui l'oggetto non censito esegue codice di terzi in automatico.

C'è poi un effetto a catena che riguarda chi sviluppa software per conto terzi. Molte software house italiane scrivono codice per banche, utility, sanità e pubblica amministrazione: soggetti che ricadono in NIS2. Una postazione di sviluppo compromessa in fornitura è un punto di ingresso verso quei clienti, esattamente lo scenario che l'articolo 21 della direttiva chiede di presidiare quando impone misure sulla sicurezza della catena di approvvigionamento e sulla gestione delle vulnerabilità. Per il fornitore questo non è un problema tecnico interno: è una clausola contrattuale che il cliente NIS2 gli chiederà prima o poi di dimostrare.

Sul piano normativo conviene fissare tre riferimenti. Se l'esecuzione di codice porta a un incidente significativo su un soggetto NIS2, restano i termini di notifica al CSIRT Italia: pre-notifica entro 24 ore e notifica entro 72. Se fra i dati raggiungibili dalla postazione ci sono dati personali — e nei dataset di collaudo capita molto più spesso di quanto si ammetta — si applicano gli articoli 32 e 33 del GDPR, con le 72 ore per la notifica al Garante. E per chi immette software sul mercato europeo, dall'11 settembre 2026 è in vigore l'obbligo di segnalazione previsto dal Cyber Resilience Act per le vulnerabilità sfruttate attivamente.

Lo stato delle correzioni è disomogeneo

AIR ha individuato il problema a maggio 2026, con proof-of-concept funzionanti contro tutti e quattro gli agenti, e lo ha comunicato ai fornitori il mese successivo. Le risposte sono andate in direzioni diverse:

  • Claude Code: corretto da Anthropic nella versione 2.1.179.
  • Codex: corretto da OpenAI nella versione 0.146.0.
  • GitHub Copilot: al momento della divulgazione Microsoft non aveva rilasciato una correzione. GitHub osserva che la propria piattaforma blocca i nomi di branch e tag simili a un hash, ma questo non protegge i marketplace ospitati altrove.
  • Gemini CLI: Google non correggerà, avendo dichiarato il prodotto deprecato, e indica la migrazione verso Antigravity. Le installazioni esistenti restano esposte a tempo indeterminato.

Poiché il controllo mancante sta dentro l'agente e non nel marketplace, nessun marketplace può chiudere la falla da solo: la verifica va fatta a valle, confrontando l'HEAD effettivo dopo il checkout con il SHA pinnato dal marketplace.

Cosa fare subito

  • Aggiornare Claude Code ad almeno la versione 2.1.179 e Codex ad almeno la 0.146.0: dove la patch esiste, è l'unica correzione completa.
  • Per GitHub Copilot, in assenza di patch, disattivare gli aggiornamenti automatici dei plugin dove la configurazione lo consente e limitare le installazioni ai marketplace ospitati su GitHub, che rifiuta i nomi di branch esadecimali a 40 caratteri.
  • Per Gemini CLI, trattare le installazioni come non correggibili: pianificare la migrazione o la rimozione, non la convivenza.
  • Costruire l'inventario dei plugin: quali agenti sono installati, su quali postazioni, con quali plugin e da quali marketplace. Senza questo elenco ogni valutazione del rischio resta un'ipotesi.
  • Limitare le sorgenti dei plugin a un elenco approvato ed evitare i marketplace ospitati su Bitbucket o su git self-hosted finché gli agenti non verificano il commit effettivamente risolto.
  • Monitorare i repository dei plugin in uso: creazione di branch anomali, cambi di proprietà, trasferimenti di manutenzione. Il takeover del repository è la seconda strada d'attacco e lascia tracce pubbliche.
  • Ridurre i privilegi della postazione di sviluppo: credenziali cloud a scadenza breve, nessuna chiave di produzione sul portatile, token CI/CD con ambito minimo. Il danno che Plugin4Shell può produrre è esattamente pari a ciò che l'account compromesso riesce a raggiungere.
  • Nei contratti con i fornitori di sviluppo, chiedere che l'uso di agenti di coding e dei relativi plugin sia dichiarato e governato. Se il committente è un soggetto NIS2, è materia di catena di approvvigionamento e non di preferenze personali dello sviluppatore.

La lezione più scomoda non riguarda git. Riguarda il fatto che l'ecosistema dei plugin per agenti AI ha adottato il vocabolario della sicurezza della supply chain — revisione, pinning, marketplace curati — prima di averne implementato i controlli. Il pin dava una garanzia che il codice non verificava, e per mesi nessuno se n'è accorto.