Plugin4Shell: la falla zero-click che ha colpito Claude Code, Codex, Copilot e Gemini CLI

Immagina di installare un plugin per il tuo agente di coding, uno di quelli che ti fanno risparmiare ore ogni giorno, e di scoprire settimane dopo che quello stesso plugin poteva eseguire codice sul tuo computer senza che tu cliccassi nulla. È lo scenario descritto da Plugin4Shell, la vulnerabilità resa pubblica il 17 settembre 2026 che ha colpito i quattro assistenti di programmazione basati sull’AI più diffusi: Claude Code di Anthropic, Codex di OpenAI, GitHub Copilot CLI di Microsoft e Gemini CLI di Google.

A scoprirla è stata AIR, una startup di sicurezza specializzata nella protezione degli agenti AI aziendali, che l’ha definita la prima vera vulnerabilità della supply chain nell’ecosistema degli agenti.

La cosa che rende Plugin4Shell diversa dalle solite falle non è tanto la sua gravità tecnica, quanto ciò che infrange: una promessa di sicurezza che davi per scontata.

Che cos’è Plugin4Shell e perché si chiama zero-click

Plugin4Shell è una vulnerabilità di tipo RCE, sigla che sta per remote code execution, cioè esecuzione di codice da remoto. In pratica consente a un aggressore di far girare il proprio codice sulla macchina di uno sviluppatore. L’aggettivo che la rende davvero preoccupante è però un altro: zero-click. Significa che alla vittima non viene chiesto di cliccare, approvare, reinstallare o confermare nulla. L’attacco si completa da solo, in silenzio.

Il meccanismo sfrutta gli aggiornamenti automatici dei plugin. Claude Code e Codex, per impostazione predefinita, aggiornano in background le estensioni installate: una comodità che si trasforma in un varco. Un plugin considerato affidabile oggi può cambiare contenuto domani, e l’agente lo scarica ed esegue senza avvisarti.

È qui che la parola supply chain entra in gioco.

Come accade per una libreria software o un pacchetto scaricato da un repository pubblico, il rischio non arriva dal codice che scrivi tu, ma da un anello della catena di cui ti fidi. Questi assistenti si appoggiano infatti a un intero ecosistema di estensioni, un fenomeno che abbiamo raccontato quando è nato lo standard aperto per rendere portabili le estensioni degli agenti AI. Un aggressore può pubblicare un plugin dall’aspetto legittimo, aspettare che venga adottato da un buon numero di sviluppatori e solo in un secondo momento modificare il repository a monte. In alternativa, può compromettere il repository di un manutentore già affermato. Il risultato è lo stesso: un numero enorme di installazioni potenzialmente esposte.

Il pin che non verificava nulla

Per capire perché Plugin4Shell ha fatto rumore devi conoscere una pratica di sicurezza molto comune tra gli sviluppatori: il pinning. Quando ancori un plugin a un commit specifico, identificato dal suo codice hash di 40 caratteri, ti aspetti di ricevere sempre e solo quella esatta versione del codice, quella che hai revisionato e di cui ti fidi. Il pin dovrebbe essere una garanzia di immutabilità.

Secondo la ricostruzione di AIR, gli agenti effettuavano il checkout del commit indicato dal pin, ma non verificavano davvero di essere finiti proprio su quel commit. Un dettaglio in apparenza minuscolo, con una conseguenza enorme: il proprietario di un repository poteva creare un ramo con lo stesso nome del codice hash e servire così codice diverso sotto un pin che restava all’apparenza intatto.

Il lucchetto sembrava chiuso, ma la porta si apriva lo stesso.

Come hanno sintetizzato diversi ricercatori, un pin non è una verifica. È un’etichetta che indica quale versione desideri, non una prova crittografica di aver ricevuto proprio quella. Plugin4Shell ha trasformato questa distinzione teorica in un problema concreto e condiviso da tutti e quattro gli strumenti analizzati, che pure sono sviluppati da aziende diverse e concorrenti.

Quali rischi corri davvero

La gravità di una falla non si misura solo da quanto è elegante l’attacco, ma da cosa mette nelle mani di chi lo sfrutta. E qui il quadro è serio, perché i plugin di questi agenti ereditano gli stessi permessi dello sviluppatore che li esegue.

Tradotto: chi riesce a far girare codice attraverso un plugin compromesso ottiene lo stesso raggio d’azione del tuo account. Parliamo dell’accesso al codice sorgente locale, alle credenziali cloud, alle chiavi SSH, ai repository interni, ai sistemi di produzione e ai segreti applicativi. In un contesto aziendale significa poter esporre codice proprietario, chiavi API, credenziali delle pipeline CI/CD e interi ambienti cloud.

È lo scenario che gli analisti di AIR hanno riassunto con un’immagine efficace, parlando della possibilità di consegnare a un attaccante le chiavi del regno.

Non un semplice fastidio, quindi, ma un rischio che tocca il cuore dei processi di sviluppo.

Vale la pena ricordare che gli agenti AI stanno diventando bersagli sempre più appetibili. Negli ultimi mesi abbiamo raccontato come centinaia di agenti AI siano stati usati per un attacco su scala globale e come un modello di frontiera sia stato impiegato per violare account reali in meno di 72 ore. Plugin4Shell aggiunge un tassello a questo mosaico: il problema non è più soltanto cosa può fare un’AI, ma quanto è fragile l’infrastruttura che le costruiamo attorno.

Come hanno risposto Anthropic, OpenAI, Microsoft e Google

La storia di Plugin4Shell non nasce a settembre. AIR ha individuato il bug a maggio 2026, sviluppando dimostrazioni di attacco funzionanti contro tutti e quattro gli agenti, e ha poi comunicato la scoperta ai rispettivi produttori il mese successivo, seguendo la prassi della divulgazione responsabile. Solo dopo il periodo concordato la vulnerabilità è diventata pubblica.

Le reazioni, però, non sono state uniformi. Anthropic ha corretto Claude Code con la versione 2.1.179, mentre OpenAI ha risolto il problema in Codex a partire dalla release 0.146.0. Due aziende su quattro hanno quindi chiuso la falla al momento della divulgazione.

Le altre due hanno scelto strade diverse.

GitHub Copilot CLI, di Microsoft, al momento dell’annuncio non disponeva ancora di una correzione lato client. Google, dal canto suo, ha deciso di non intervenire su Gemini CLI perché il prodotto è ormai deprecato, cioè destinato a essere dismesso. Una scelta legittima sul piano commerciale, che lascia però gli utenti ancora attivi su quello strumento senza una patch ufficiale.

C’è comunque un dato che aiuta a mantenere la calma: ad oggi non risultano abusi reali di questa tecnica, nessuna segnalazione di violazioni e nessuna perdita di dati documentata. La finestra di rischio è esistita, ma non ci sono prove che qualcuno l’abbia sfruttata sul campo prima delle correzioni.

Cosa puoi fare per proteggerti

Se usi uno di questi strumenti nel tuo lavoro quotidiano, la buona notizia è che le contromisure sono alla tua portata e non richiedono competenze da esperto di sicurezza. Il primo passo, il più importante, è aggiornare. Assicurati di avere Claude Code alla versione 2.1.179 o successiva e Codex alla 0.146.0 o successiva, così da ricevere le correzioni già distribuite.

Se lavori con GitHub Copilot CLI o con Gemini CLI la prudenza deve essere maggiore, dato che una patch ufficiale non è disponibile. In questi casi conviene valutare con attenzione quali plugin tieni installati e ridurre al minimo le estensioni di terze parti non strettamente necessarie.

Più in generale, vale qualche principio di igiene digitale utile a prescindere da questa specifica falla. Rivedi periodicamente i plugin attivi ed elimina quelli che non usi, preferisci estensioni con manutentori affidabili e una storia consolidata e, se il tuo flusso di lavoro lo consente, tieni sotto controllo gli aggiornamenti automatici, così da sapere sempre quale codice stai eseguendo.

La comodità dell’automazione è preziosa, ma va bilanciata con la consapevolezza di ciò che quell’automazione può scaricare al posto tuo.

Le aziende, infine, dovrebbero trattare i plugin degli agenti AI come qualsiasi altra dipendenza software, sottoponendoli a inventario, revisione e monitoraggio. Sapere quali estensioni girano sulle macchine dei propri sviluppatori è il presupposto per reagire in fretta quando emerge una vulnerabilità come questa.

Perché Plugin4Shell conta più di una singola patch

Plugin4Shell verrà probabilmente ricordata non per i danni causati, che al momento risultano nulli, ma per ciò che ha rivelato. Gli agenti AI che scrivono codice sono passati in pochi mesi da curiosità per addetti ai lavori a strumenti presenti in milioni di postazioni di lavoro, e con loro è cresciuto un ecosistema di plugin che replica le stesse dinamiche, e gli stessi rischi, del software tradizionale.

La differenza è che qui l’AI agisce con grande autonomia e con permessi ampi, spesso proprio quelli dello sviluppatore. Una falla nella catena di fiducia non espone un singolo dato, ma potenzialmente l’intero ambiente di lavoro.

La lezione è semplice e vale ben oltre questo episodio: la sicurezza di un agente non finisce nel modello.

Comprende anche gli strumenti che gli permettiamo di usare, i plugin che installiamo e i meccanismi con cui li aggiorniamo. Vale la pena ricordare che la stessa AI viene ormai usata anche in senso opposto, per scovare vulnerabilità che gli esseri umani non avevano notato: la partita tra attacco e difesa si gioca sempre più spesso tra sistemi automatici.

Se vuoi restare aggiornato su come l’intelligenza artificiale sta cambiando la sicurezza informatica e il lavoro di chi sviluppa software, continua a seguire i nostri approfondimenti e condividi questo articolo con chi, nel tuo team, usa ogni giorno un assistente di coding. Una patch installata in tempo può fare tutta la differenza.