Il problema di Plugin4Shell non si trova nei modelli IA utilizzati dagli agenti di coding ma nella distribuzione dei plugin, uno degli elementi che dovrebbe rendere più sicuro il loro ecosistema. La vulnerabilità, individuata dalla società di sicurezza Air, riguarda Claude Code, OpenAI Codex, GitHub Copilot e Gemini CLI e può trasformare un componente apparentemente affidabile in un vettore per l’esecuzione remota di codice senza alcuna interazione dell’utente.

Il punto critico è il meccanismo di SHA pinning, utilizzato dagli agenti per fare in modo che un plugin venga installato a partire da uno specifico commit Git già verificato. L’idea è che l’agente dovrebbe scaricare esattamente il codice corrispondente a un determinato hash. In questo modo, anche se il repository originale venisse successivamente compromesso, il software già approvato dovrebbe rimanere quello effettivamente eseguito.

Plugin4Shell dimostra però che questa garanzia può essere aggirata. Secondo i ricercatori di Air, gli agenti verificano quale riferimento viene richiesto, ma non controllano correttamente che il codice effettivamente finito nella directory di lavoro corrisponda allo SHA previsto. Un aggressore che abbia preso il controllo del repository può quindi manipolare la risoluzione del riferimento e fare installare una versione malevola mantenendo apparentemente intatto il meccanismo di sicurezza.

È qui che entra in gioco il carattere zero-click dell’attacco. I plugin degli agenti possono infatti essere aggiornati automaticamente e se un componente già installato viene sostituito a monte e il processo di aggiornamento non verifica correttamente il commit effettivamente eseguito, il codice malevolo può arrivare sulla macchina senza che lo sviluppatore debba scaricare manualmente un nuovo pacchetto o autorizzare un comando.

Le conseguenze dipendono naturalmente dai privilegi concessi all’agente. Un coding agent non è però un semplice chatbot, ma può leggere repository, accedere a file locali, eseguire comandi, interagire con strumenti di sviluppo e, in determinati ambienti, raggiungere risorse aziendali e credenziali. Un plugin compromesso eredita quindi potenzialmente parte di queste autorizzazioni. Air descrive proprio questo aspetto come uno degli elementi che rendono particolarmente rilevante l’attacco per le aziende.

6aa90f1ade0dd92b6788b81b_image (9)

La ricerca evidenzia inoltre un problema più ampio nella catena di approvvigionamento del software IA. Tradizionalmente, per compromettere un’applicazione era necessario attaccare direttamente il programma, il suo sviluppatore o le dipendenze utilizzate. Nel caso degli agenti, la superficie d’attacco comprende invece anche marketplace, skill e plugin che ampliano le capacità operative del sistema. L’idea di Air è che Plugin4Shell rappresenti un attacco alla distribuzione dell’agente, anziché al modello o al motore di esecuzione.

Gli scenari individuati sono principalmente due:

  • Un aggressore può pubblicare un plugin apparentemente innocuo su un marketplace, superare i controlli iniziali e successivamente sostituire il codice nel repository
  • Un aggressore può impossessarsi del repository di uno sviluppatore legittimo e utilizzarlo per distribuire la versione modificata agli agenti che hanno già installato quel componente

Sul fronte delle correzioni la situazione è diversa da prodotto a prodotto. Anthropic ha corretto la vulnerabilità in Claude Code 2.1.179, mentre OpenAI l’ha risolta in Codex 0.146.0. Google ha invece comunicato che Gemini CLI è stato deprecato e non riceverà una patch; agli utenti viene indicata la migrazione verso il nuovo ambiente agentico Antigravity, che non risulta interessato da questo specifico attacco.

Più controverso è il caso Microsoft. Air sostiene che Microsoft Copilot rimanga vulnerabile, mentre GitHub ha dichiarato che GitHub Copilot non sarebbe interessato grazie a una mitigazione che impedisce di creare su GitHub rami o tag con nomi corrispondenti a commit SHA. I ricercatori contestano però che questa protezione sia sufficiente, perché i marketplace supportati dagli agenti possono utilizzare anche infrastrutture Git differenti, come Bitbucket o server self-hosted.

La distinzione è importante perché sposta il problema dal singolo marketplace all’implementazione del client. Se è l’agente a risolvere il riferimento Git e a decidere quale codice eseguire, un marketplace può ridurre alcuni vettori di attacco ma non garantire da solo l’integrità del risultato. La verifica realmente efficace deve avvenire dopo il checkout, confrontando il commit effettivamente presente nell’albero di lavoro con quello dichiarato come attendibile.