La vulnerabilità Plugin4Shell negli agenti AI ha aggirato i plugin attendibili, lasciando due strumenti di coding senza patch

Plugin4Shell ha compromesso una protezione fondamentale in quattro agenti AI per la programmazione, nonostante gli utenti seguissero la procedura prevista per installare plugin sottoposti a revisione. La società di sicurezza AIR afferma che la falla ha interessato Claude Code, OpenAI Codex, GitHub Copilot e Gemini CLI. I suoi ricercatori hanno dimostrato l'esecuzione remota di codice funzionante contro tutti e quattro i prodotti.

Anthropic e OpenAI hanno rilasciato correzioni dopo aver ricevuto la segnalazione di AIR. Quando ha pubblicato i propri risultati il 17 settembre 2026, AIR ha riferito di non aver riscontrato una patch corrispondente per GitHub Copilot. Ha inoltre affermato che Google non avrebbe corretto il comportamento interessato di Gemini CLI, indirizzando invece gli utenti verso Antigravity.

Questa risposta disomogenea è il problema centrale. I marketplace di plugin promettono che la revisione e il pinning dei commit proteggano gli sviluppatori dalle modifiche al codice dopo l'approvazione. Secondo quanto riportato, la vulnerabilità Plugin4Shell negli agenti AI ha infranto questa promessa senza richiedere un'installazione imprudente, un'approvazione sospetta o un nuovo clic.

Plugin4Shell ha trasformato un aggiornamento attendibile in esecuzione remota di codice

L'attacco prendeva di mira il processo di distribuzione del plugin, non il modello linguistico che decide come rispondere a un prompt.

Gli agenti AI per la programmazione supportano sempre più plugin, skill, estensioni e altri componenti aggiuntivi. Questi pacchetti possono personalizzare i flussi di lavoro, connettere servizi o eseguire codice negli ambienti di sviluppo. Spesso ereditano la capacità dell'agente di accedere ai file, eseguire comandi shell e interagire con sistemi autenticati.

Questo accesso rende un plugin di un agente più simile a un'applicazione locale che a un prompt testuale passivo. Se codice dannoso raggiunge la directory del plugin, può operare con le autorizzazioni concesse allo sviluppatore che esegue l'agente.

AIR afferma che Plugin4Shell ha raggiunto questo punto aggirando il pinning SHA. Uno SHA è un identificatore crittografico comunemente usato per indicare uno specifico commit Git. Fissare un plugin a tale identificatore dovrebbe mantenere immutato il suo codice installato, anche quando il repository cambia in seguito.

Secondo la ricerca su Plugin4Shell, gli agenti interessati richiedevano un commit fissato ma non verificavano il commit effettivamente estratto. Un attaccante che controllasse il repository upstream poteva sfruttare il comportamento di risoluzione dei nomi di Git e sostituire codice diverso.

Il record del marketplace poteva continuare a mostrare l'identificatore di commit previsto. L'agente poteva anche segnalare un'installazione riuscita. Tuttavia, i file nella directory di lavoro provenivano da un branch controllato dall'attaccante anziché dal commit sottoposto a revisione.

AIR ha descritto due percorsi di accesso pratici. Un attaccante poteva pubblicare un plugin legittimo, costruirne l'adozione e rendere dannoso il repository durante un aggiornamento successivo. In alternativa, poteva assumere il controllo del repository che supportava un plugin esistente.

Il secondo percorso è importante perché sposta la responsabilità dagli autori dei singoli plugin. Un plugin può nascere come progetto legittimo e superare ogni revisione. Il suo repository può diventare ostile solo dopo che sviluppatori e team di sicurezza vi hanno riposto fiducia.

AIR afferma che i ricercatori hanno individuato il problema nel maggio 2026 e lo hanno segnalato ai quattro fornitori a giugno. L'azienda ha pubblicato il proprio resoconto tecnico il 17 settembre. Help Net Security ha riportato i risultati il giorno successivo.

Nessuna prova pubblica citata da nessuna delle due organizzazioni mostrava che Plugin4Shell fosse stato sfruttato contro vittime reali prima della divulgazione. L'impatto dimostrato deriva dai test proof-of-concept di AIR, non da una campagna criminale documentata.

Questa distinzione limita ciò che si può affermare su una compromissione immediata. Non riduce l'importanza del controllo compromesso. Un attacco riuscito eseguirebbe codice tramite un componente che le organizzazioni avevano già esaminato e approvato.

Il problema segue inoltre precedenti ricerche di AIR sulla distribuzione dei plugin. L'azienda afferma che una skill di test ha raggiunto oltre 26.000 agenti prima della rimozione. Una ricerca separata avrebbe identificato 925 skill dirottate che interessavano 134.000 agenti.

Questi numeri provengono da AIR e non sono stati riprodotti in modo indipendente nella divulgazione di Plugin4Shell. Illustrano l'argomentazione più ampia dei ricercatori: ottenere distribuzione e compromettere repository upstream sono fasi realistiche, non semplici prerequisiti teorici.

Come la vulnerabilità Plugin4Shell negli agenti AI ha aggirato il pinning SHA

Plugin4Shell ha funzionato perché ciascun agente interessato si fidava del riferimento Git richiesto invece di verificare il commit finale effettivamente estratto.

Secondo quanto riportato, Claude Code, Codex e GitHub Copilot condividevano una variante. I loro installer di plugin clonavano un repository e passavano a git checkout l'identificatore di commit fissato di 40 caratteri.

Git consente nomi di branch che assomigliano a identificatori di commit in molte configurazioni di hosting. Quando un nome può identificare sia un branch sia un oggetto, Git può risolverlo come riferimento mostrando al contempo un avviso di ambiguità.

Un attaccante che controllasse il repository del plugin poteva creare un branch denominato esattamente come il commit fissato. Avrebbe quindi reso quel branch quello predefinito del repository e lo avrebbe puntato verso codice dannoso.

Il clone iniziale avrebbe scaricato il branch predefinito dell'attaccante. Il checkout successivo avrebbe potuto risolvere l'apparente identificatore di commit a quel branch locale. L'agente avrebbe quindi caricato o eseguito file diversi da quelli esaminati dal marketplace.

Questa tecnica non funziona in modo identico su ogni servizio di hosting. GitHub blocca i nomi di branch e tag che assomigliano a identificatori completi di oggetti Git, secondo le sue restrizioni sui nomi dei branch.

Tuttavia, AIR afferma che Bitbucket e i servizi Git self-hosted possono accettare tali nomi. Alcuni marketplace di agenti supportano ufficialmente repository ospitati al di fuori di GitHub, lasciando esposta la configurazione più ampia.

Secondo quanto riportato, Gemini CLI usava un percorso separato per ottenere lo stesso risultato. Il suo installer recuperava il commit fissato e quindi eseguiva un checkout su FETCH_HEAD, un riferimento Git che normalmente punta al contenuto recuperato.

AIR ha scoperto che un repository poteva usare FETCH_HEAD come nome del proprio branch predefinito. Il checkout poteva quindi risolversi in quel branch anziché nel file speciale contenente il commit recuperato.

Entrambe le varianti dipendevano dall'assenza di un confronto finale. Dopo aver completato il checkout, l'agente doveva risolvere HEAD e verificare che corrispondesse allo SHA fissato dal marketplace.

Questo controllo è piccolo, ma la sua posizione è importante. Un marketplace non può confermare cosa un client abbia infine collocato nel proprio albero di lavoro locale. La verifica deve avvenire all'interno dell'agente che esegue il clone e il checkout.

L'etichetta zero-click deriva dagli aggiornamenti in background. AIR afferma che Claude Code e Codex aggiornano automaticamente i plugin installati per impostazione predefinita. Una sostituzione dannosa potrebbe quindi arrivare dopo che un marketplace ha modificato il proprio pin, senza un'altra decisione di installazione.

La vittima non dovrebbe trovare un nuovo plugin dannoso. L'attaccante prenderebbe di mira un plugin già presente sulla macchina e attenderebbe il processo di aggiornamento dell'agente.

L'esecuzione remota di codice, o RCE, significa che istruzioni controllate dall'attaccante vengono eseguite sul sistema di destinazione. L'estensione risultante dipende dall'account, dall'ambiente, dal sandbox, dalle credenziali e dall'accesso di rete disponibili all'agente interessato.

AIR descrive il potenziale impatto come equivalente all'accesso detenuto dal dipendente che esegue lo strumento. Si tratta di una descrizione del caso peggiore, non di una misurazione universale di ogni installazione.

Un agente strettamente isolato potrebbe esporre soltanto uno spazio di lavoro temporaneo. Un agente installato localmente con credenziali cloud, repository di codice sorgente, chiavi di firma o accesso alla produzione crea un raggio d'impatto potenziale molto più ampio.

Questa variabilità è il motivo per cui il solo inventario delle versioni è insufficiente. I team di sicurezza devono anche sapere dove viene eseguito ciascun agente, quali plugin carica e quali credenziali sono disponibili entro quel confine di esecuzione.

La revisione dei plugin ha funzionato come previsto, ma il codice installato è comunque cambiato

Il conflitto centrale è tra la promessa di una revisione immutabile e la realtà della risoluzione Git lato client.

I controlli della supply chain software spesso separano l'approvazione dall'esecuzione. Un revisore valuta una versione nota, ne registra il digest e consente ai sistemi di installare soltanto quella versione.

Questo modello presuppone che il digest identifichi i file che verranno eseguiti. Secondo quanto riportato, Plugin4Shell ha preservato il pin visibile interrompendo il collegamento tra quel pin e l'albero di lavoro finale.

Questo è più grave che avvisare gli utenti contro estensioni sconosciute. I ricercatori affermano che l'attacco funziona comunque quando un plugin proviene da un marketplace attendibile, supera la revisione e rimane fissato.

Le linee guida di sicurezza basate soltanto sulla reputazione del marketplace non coglierebbero quindi il passaggio vulnerabile. L'attaccante non deve compromettere il database del marketplace se l'agente locale può essere ingannato durante il checkout.

La stessa limitazione si applica ai cataloghi interni di plugin. Un'azienda potrebbe esaminare ogni pacchetto e replicare i metadati approvati. Questi controlli rimangono incompleti se i client dei dipendenti non convalidano il commit risolto.

AIR definisce Plugin4Shell la prima vulnerabilità della supply chain dell'ecosistema degli agenti AI. Questa formulazione è una caratterizzazione dell'azienda e merita una certa cautela.

Gli strumenti di sviluppo AI hanno già affrontato avvelenamento dei repository, prompt injection, file di configurazione dannosi e vulnerabilità legate alle estensioni. Plugin4Shell è più circoscritta in un senso perché si concentra sui componenti aggiuntivi degli agenti fissati e sul loro percorso di aggiornamento.

Tuttavia, il meccanismo espone una distinta falla di fiducia. Attacca il modo in cui funzionalità dell'agente sottoposte a revisione viaggiano da un repository alla macchina di uno sviluppatore.

Ricerche recenti mostrano che questo non è un punto di pressione isolato. Wiz ha divulgato GhostApproval nel luglio 2026 dopo aver testato sei assistenti AI per la programmazione. Quel problema usava collegamenti simbolici per raggiungere file al di fuori dei previsti confini dello spazio di lavoro.

I risultati su GhostApproval hanno interessato prodotti di Amazon, Anthropic, Augment, Cursor, Google e Windsurf. Le risposte dei fornitori sono variate, con diverse correzioni e almeno una decisione contestata sul modello di minaccia.

GhostApproval e Plugin4Shell usano primitive tecniche diverse. Uno sfrutta la risoluzione dei percorsi tramite collegamenti simbolici. L'altro, secondo quanto riportato, sfrutta la risoluzione dei riferimenti Git durante l'installazione e gli aggiornamenti dei plugin.

Il modello che li collega è un divario tra la decisione visibile dell'utente e l'azione reale del sistema. Un percorso appare locale ma si risolve altrove. Un pin appare immutabile ma si risolve in codice diverso.

Le sole richieste di autorizzazione non possono correggere questa discrepanza. Gli utenti non possono prendere decisioni informate quando l'interfaccia mostra il nome attendibile mentre l'operazione sottostante punta a qualcos'altro.

Anthropic ha descritto pubblicamente l'isolamento del filesystem e della rete come protezioni complementari per Claude Code. Il suo modello di sandboxing mira a impedire che un processo iniettato raggiunga file sensibili o destinazioni di rete non autorizzate.

Il sandboxing può ridurre l'impatto del codice dannoso nei plugin. Non sostituisce una verifica accurata dei pacchetti, in particolare quando i plugin vengono eseguiti al di fuori delle stesse restrizioni o ricevono autorizzazioni più ampie.

Le aziende necessitano quindi di due confini indipendenti. Il processo di installazione deve verificare che venga effettivamente installato il codice sottoposto a revisione. Il runtime deve limitare ciò che quel codice può raggiungere dopo l'esecuzione.

Un errore in uno dei due livelli non dovrebbe trasformarsi automaticamente nella compromissione di una workstation o di un account cloud. Plugin4Shell è rilevante perché molte distribuzioni di agenti combinano ancora estensioni modificabili con preziose credenziali locali.

Quattro agenti di coding hanno prodotto quattro diversi esiti di sicurezza

La divulgazione ha rivelato un processo di patch frammentato tra strumenti che implementano flussi di lavoro per plugin simili.

AIR afferma che Anthropic ha corretto la vulnerabilità di Claude Code nella versione 2.1.179. L'azienda ha registrato il 17 giugno 2026 come data in cui Anthropic ha confermato la correzione.

Secondo AIR, OpenAI ha corretto il comportamento interessato di Codex nella versione 0.146.0. La cronologia della ricerca afferma che l'azienda ha verificato tale release come corretta il 12 agosto.

Gli utenti di questi prodotti non dovrebbero presumere che gli aggiornamenti automatici siano stati completati correttamente. Workstation gestite, ambienti offline, blocchi delle dipendenze e sistemi di distribuzione interni possono lasciare installate versioni precedenti.

Le organizzazioni dovrebbero interrogare gli endpoint effettivi e confrontarne le versioni con le release corrette. Dovrebbero inoltre riavviare le sessioni di lunga durata se il processo di distribuzione non sostituisce i processi degli agenti già attivi.

GitHub Copilot presenta un problema diverso. AIR ha dichiarato che Microsoft ha ricevuto la stessa segnalazione di vulnerabilità, ma non aveva distribuito una correzione quando la ricerca è diventata pubblica.

GitHub aveva recentemente ampliato i controlli centralizzati per le operazioni degli agenti. Il suo annuncio del 9 settembre affermava che gli amministratori potevano bloccare, consentire o richiedere approvazione per comandi shell, operazioni sui file e domini di rete attraverso le managed agent permissions.

Questi controlli possono limitare le conseguenze, ma non sono prova di una patch per Plugin4Shell. Un installer senza patch e una policy di runtime restrittiva affrontano fasi diverse dell'attacco.

Gli amministratori di Copilot dovrebbero pertanto cercare un avviso specifico per il prodotto, una versione corretta o una conferma del fornitore. Fino ad allora, le organizzazioni possono sospendere gli aggiornamenti dei plugin del marketplace o limitare gli agenti a repository approvati sotto il loro controllo.

Gemini CLI ha lo stato più complicato. AIR afferma che Google ha confermato il 4 agosto che non avrebbe corretto il flusso di lavoro interessato e ha consigliato la migrazione ad Antigravity.

Google aveva già iniziato a spostare gli utenti individuali da Gemini CLI ad Antigravity CLI. Un annuncio di giugno affermava che Gemini CLI aveva smesso di servire richieste per gli account individuali, mentre l'uso aziendale e tramite chiave API restava disponibile.

Tuttavia, il precedente avviso di transizione di Google affermava anche che il progetto open-source Gemini CLI avrebbe continuato a ricevere aggiornamenti dei modelli, correzioni di bug e aggiornamenti di sicurezza per i clienti enterprise.

Questa formulazione pubblica non si allinea chiaramente con l'affermazione secondo cui ogni installazione di Gemini CLI resterà vulnerabile indefinitamente. Lascia agli amministratori un'importante lacuna di verifica.

Il changelog di Google di settembre mostra che le release di Gemini CLI sono proseguite dopo la transizione dei consumatori. Elenca anche misure di hardening della sicurezza non correlate allo specifico difetto di checkout. Tale attività non dimostra una correzione per Plugin4Shell.

La conclusione prudente è più circoscritta. AIR ha segnalato l'assenza di una patch Plugin4Shell per Gemini CLI al momento della divulgazione e ha raccomandato Antigravity. Google ha continuato a mantenere alcune parti di Gemini CLI per l'uso enterprise, ma nessuna nota di rilascio citata identifica questa specifica correzione.

Gli utenti enterprise non dovrebbero dedurre la sicurezza da formulazioni generiche sulla manutenzione. Hanno bisogno di una conferma diretta che la loro release verifichi il commit finale sottoposto a checkout dopo l'installazione o l'aggiornamento di un'estensione.

Dovrebbero inoltre evitare di considerare la migrazione come un semplice cambio di nome. Trasferire skill, hook, server MCP e credenziali in un nuovo agente può riprodurre altri rischi se le configurazioni vengono trasferite senza revisione.

AIR afferma che Antigravity non utilizza il meccanismo di SHA pinning dei plugin sfruttato da Plugin4Shell. Ciò significa che questo specifico percorso non si applica, in base all'analisi dei ricercatori.

Non significa che Antigravity sia immune da plugin malevoli, prompt injection, strumenti non sicuri o futuri fallimenti della supply chain. I team di sicurezza dovrebbero mantenere gli stessi requisiti di isolamento e minimo privilegio dopo la migrazione.

Le quattro risposte rivelano un problema di governance che va oltre questo bug. Funzionalità simili possono essere distribuite su più agenti senza convenzioni condivise per la divulgazione, punteggi di gravità comuni o correzioni sincronizzate.

Gli sviluppatori devono seguire changelog e dichiarazioni dei fornitori separati. Gli amministratori enterprise devono poi tradurre questi riscontri disomogenei in un'unica postura di sicurezza applicabile.

Cosa dovrebbero cambiare immediatamente i team di sviluppo

La prima priorità è fermare gli aggiornamenti dei plugin vulnerabili, verificare le versioni degli agenti e ridurre le credenziali disponibili a ogni agente di coding.

Per Claude Code, le organizzazioni dovrebbero portare tutte le installazioni alla versione 2.1.179 o successiva. Per Codex, AIR identifica la versione 0.146.0 come release corretta.

I team dovrebbero verificare le versioni tramite l'inventario degli endpoint anziché tramite sondaggi. Gli sviluppatori possono usare vari agenti di coding su terminali locali, estensioni IDE, workspace remoti e sistemi CI.

Per GitHub Copilot, gli amministratori dovrebbero richiedere indicazioni esplicite sulla correzione a GitHub o Microsoft. Non dovrebbero considerare miglioramenti non correlati alle autorizzazioni come conferma che la vulnerabilità di checkout sia stata risolta.

Dove la funzionalità dei plugin non è essenziale, disabilitare i pacchetti di marketplace di terze parti offre la più chiara riduzione temporanea del rischio. Le organizzazioni che non possono disabilitarli dovrebbero sospendere gli aggiornamenti automatici e limitare le fonti dei repository.

Gli utenti di Gemini CLI dovrebbero valutare la migrazione ad Antigravity, in particolare quando utilizzano estensioni del marketplace. I clienti enterprise dovrebbero inoltre richiedere una conferma scritta sullo stato della loro esatta release di Gemini CLI.

Rimuovere un plugin interessato dopo la divulgazione è utile ma incompleto. Un pacchetto compromesso potrebbe aver creato persistenza, modificato file di avvio, copiato credenziali o alterato repository prima della rimozione.

I responsabili della risposta agli incidenti dovrebbero esaminare la cronologia degli aggiornamenti dei plugin, l'attività Git, l'esecuzione dei processi, le connessioni di rete e le modifiche ai file sensibili. La finestra temporale pertinente inizia prima della divulgazione pubblica se erano attivi aggiornamenti automatici vulnerabili.

I team dovrebbero ruotare le credenziali quando la telemetria indica che è stato eseguito codice inatteso di un plugin. I bersagli prioritari includono token di controllo del codice sorgente, credenziali cloud, chiavi di pubblicazione dei pacchetti, materiale di firma e segreti archiviati negli ambienti shell.

L'ambito delle credenziali conta quanto la rotazione. Un agente di coding AI non dovrebbe ereditare un accesso alla produzione senza restrizioni solo perché lo sviluppatore che lo avvia possiede tali autorizzazioni.

Identità separate per gli agenti rendono più facile contenere e verificare azioni anomale. Anche i token di breve durata limitano il valore delle credenziali raccolte da una workstation.

L'isolamento del runtime fornisce un ulteriore livello. L'accesso ai file dovrebbe essere limitato per impostazione predefinita al progetto attivo, mentre l'accesso alla rete dovrebbe usare una allowlist ristretta appropriata per l'attività.

L'esecuzione della shell richiede confini simili. Un plugin che può invocare qualsiasi comando con l'account di uno sviluppatore può aggirare molti controlli applicati soltanto al codice sorgente generato.

Le organizzazioni dovrebbero verificare se le regole di sandbox coprono i sottoprocessi creati da plugin, hook, gestori di pacchetti e server MCP. Una restrizione sugli strumenti diretti del modello potrebbe non coprire ogni processo di estensione.

Anche la governance dei plugin necessita di prove più solide. Un catalogo interno dovrebbe memorizzare il commit esaminato, l'origine del repository, l'identificatore dell'albero risolto, il revisore, la data di approvazione e la versione distribuita.

L'installer dovrebbe convalidare il HEAD risolto dopo il checkout. Se non corrisponde al commit approvato, l'installazione deve interrompersi anziché avvertire e continuare.

I team di sicurezza possono testare questo comportamento senza riprodurre un'esecuzione malevola. Un repository controllato può presentare riferimenti ambigui mentre il sistema di convalida verifica se l'installazione si interrompe in modo sicuro.

Il risultato dovrebbe entrare a far parte dei test di approvvigionamento e accettazione interni. I fornitori dovrebbero essere in grado di spiegare come i loro agenti verificano il contenuto dei plugin dopo clonazione, fetch e aggiornamento.

I team hanno inoltre bisogno di una registrazione affidabile del motivo per cui esiste ogni plugin. Una base di conoscenza ingegneristica ricercabile può collegare approvazioni, proprietari, incidenti e decisioni di sostituzione.

Questa documentazione non impedisce lo sfruttamento. Riduce il tempo necessario per identificare i team interessati e rimuovere integrazioni rischiose quando emerge un'altra divulgazione.

Infine, gli sviluppatori non dovrebbero essere incolpati per aver fatto affidamento su un pin pubblicizzato. Secondo quanto riferito, Plugin4Shell ha aggirato un controllo progettato per rendere ragionevole tale fiducia.

L'azione correttiva riguarda il codice dei fornitori, le policy enterprise e l'architettura di runtime. Formare gli utenti affinché ispezionino ogni aggiornamento non può compensare un installer che esegue codice diverso dal digest approvato.

Tre segnali mostreranno se la sicurezza dei plugin degli agenti sta migliorando

Il prossimo test è se i fornitori trasformeranno questa divulgazione in controlli di installazione verificabili anziché in promesse di sicurezza più ampie.

Il primo segnale è una correzione specifica per GitHub Copilot. Gli amministratori dovrebbero cercare un avviso di sicurezza, un identificatore di release o una dichiarazione tecnica che confermi la verifica del commit dopo il checkout.

Un aggiornamento generale di Copilot non risponderà alla domanda. La prova pertinente è se il client risolve il HEAD dell'albero di lavoro e lo confronta con il pin del marketplace.

Se GitHub documenta tale comportamento e lo distribuisce su tutte le superfici Copilot supportate, l'attuale lacuna nelle patch si ridurrà. Un silenzio prolungato rafforzerebbe le preoccupazioni su una gestione incoerente delle vulnerabilità.

Il secondo segnale è il chiarimento di Google per gli utenti enterprise di Gemini CLI. Il linguaggio pubblico sulla transizione afferma che l'accesso enterprise e la manutenzione della sicurezza continuano, mentre AIR segnala l'assenza di una patch Plugin4Shell.

Google può risolvere questa tensione nominando le versioni interessate, spiegando se esiste una correzione e definendo le date di supporto. Un avviso specifico aiuterebbe i team a decidere tra patch e migrazione.

Se Gemini CLI riceve una verifica del commit convalidata, lo stato al momento della divulgazione riportato da AIR diventa obsoleto. Se Google conferma che non la implementerà, le organizzazioni dovrebbero trattare la migrazione come un requisito di sicurezza anziché come una preferenza di prodotto.

Il terzo segnale è l'adozione, a livello di marketplace, di un comportamento del client verificabile. I marketplace non possono imporre da soli il checkout finale, ma possono richiedere agenti compatibili e rifiutare configurazioni di repository non sicure.

Le modifiche utili includerebbero manifest firmati, artefatti di pacchetto immutabili, attestazioni di provenienza e ricevute di installazione contenenti il commit risolto. Ogni controllo dovrebbe rimanere testabile in modo indipendente.

I fornitori di agenti dovrebbero inoltre dichiarare se i plugin vengono eseguiti nella stessa sandbox dei comandi generati. Un pacchetto verificato può comunque essere compromesso a monte prima della revisione o contenere una vulnerabilità trascurata.

La lezione più ampia non è che i plugin siano intrinsecamente insicuri. È che gli agenti autonomi trasformano gli errori di packaging in azioni eseguite con privilegi da sviluppatore.

Secondo quanto riferito, Plugin4Shell ha attraversato quattro prodotti concorrenti perché le loro implementazioni si basavano sulla stessa assunzione non verificata. L'identificatore Git richiesto è stato trattato come equivalente al codice effettivamente installato.

Sviluppatori e responsabili della sicurezza dovrebbero ora porre una domanda diretta a ogni fornitore di agenti di coding: cosa dimostra che il codice esaminato è il codice in esecuzione sulla macchina?

Finché Copilot e Gemini CLI non avranno risposte specifiche per il prodotto, le organizzazioni interessate dovrebbero limitare l'uso dei plugin, verificare ogni versione degli agenti e isolare le credenziali. I team che usano Claude Code o Codex corretti dovrebbero comunque verificare le estensioni installate e confermare che gli aggiornamenti abbiano raggiunto ogni endpoint.

La vulnerabilità dell’agente AI Plugin4Shell è, in ultima analisi, un test della visibilità operativa. La vostra organizzazione è in grado di identificare ciascun agente, i relativi plugin, la versione e i privilegi prima che venga eseguito il prossimo aggiornamento in background?