Plugin4Shell rompe i pin SHA: quattro coding agent possono eseguire codice diverso

🛡️ Executive Summary

• Plugin4Shell sfrutta l’assenza di una verifica finale tra commit SHA approvato e codice realmente materializzato dal client Git.
• Air Security coinvolge Claude Code, Codex, GitHub Copilot e Gemini CLI; Claude Code 2.1.179 e Codex 0.146.0 risultano corretti.
• Il rischio reale dipende dal repository: GitHub vieta branch simili a SHA, restringendo fortemente la variante principale sui marketplace predefiniti.

Un plugin revisionato e bloccato su uno specifico commit SHA può non essere il codice che un coding agent finisce realmente per installare. È il problema scoperto da Air Security in Claude Code, OpenAI Codex, GitHub Copilot e Gemini CLI e battezzato Plugin4Shell. La falla nasce nel livello che dovrebbe garantire l’immutabilità della supply chain: il client richiede un commit approvato, ma nelle implementazioni vulnerabili non verifica che HEAD corrisponda effettivamente allo SHA previsto dopo il checkout. Il risultato può essere l’esecuzione di un plugin differente con i privilegi dello sviluppatore. La portata pratica è però più circoscritta del claim “milioni di agenti”: il vettore principale non funziona allo stesso modo sui repository GitHub.

Il pin SHA esiste, ma nessuno controlla quale commit è stato installato

La ricerca originale di Air Security su Plugin4Shell individua un errore concettualmente semplice. Un marketplace può aver revisionato il plugin alla versione associata, per esempio, a un commit SHA di 40 caratteri e registrare quel valore come riferimento immutabile. Il coding agent recupera successivamente il repository e chiede a Git di effettuare il checkout di quello SHA, ma non confronta il commit realmente materializzato con quello approvato. Su host Git che consentono a un repository owner di creare un branch con lo stesso nome del commit SHA, Git può risolvere il riferimento verso il branch invece che verso l’oggetto atteso. Il proprietario malevolo può quindi modificare quel branch dopo la revisione e consegnare codice differente mantenendo apparentemente invariato il pin registrato dal marketplace.

Il problema non riguarda il modello linguistico né una prompt injection. È una falla nella software supply chain dell’agente, analoga per principio ad altri casi nei quali l’automazione invoca Git con trust boundary insufficienti. GitSpawn aveva già mostrato come configurazioni Git controllate da un repository potessero arrivare a RCE nei coding agent.

Leggi anche: Estensioni e coding assistant diventano vettori d’attacco tra BragJack e Shai-Hulud

OpenAI ha corretto Codex verificando HEAD dopo il checkout

Nel caso di OpenAI Codex, la correzione è verificabile direttamente nel repository del progetto. La pull request 34644 “Verify Git plugin SHA checkouts”, integrata il 22 luglio 2026, spiega esplicitamente che Git può interpretare uno SHA richiesto come nome di branch quando il branch predefinito remoto presenta lo stesso nome, facendo materializzare un commit differente da quello fissato dal marketplace. La patch aggiunge esattamente il controllo che mancava: dopo il checkout, Codex risolve HEAD e rifiuta il plugin se il commit ottenuto non coincide perfettamente con lo SHA richiesto. Il fix è arrivato in Codex 0.146.0.

Air Security attribuisce ad Anthropic una correzione equivalente in Claude Code 2.1.179. In questo caso le release note pubbliche della versione non menzionano però Plugin4Shell, quindi il dato sulla remediation deriva dalla disclosure dei ricercatori. Air riferisce inoltre che GitHub Copilot non disponeva ancora di una patch al momento della pubblicazione e che Google non intende correggere il vecchio Gemini CLI, indirizzando gli utenti verso Antigravity. La superficie non è marginale perché questi plugin possono ereditare filesystem, token, repository, shell e accessi cloud dello sviluppatore. È lo stesso ampliamento del perimetro già osservato con AgentBaiting, dove repository costruiti per essere scoperti dagli agenti AI distribuivano malware.

GitHub limita il vettore principale e ridimensiona il rischio dei marketplace default

Il dettaglio più importante per misurare Plugin4Shell è che non tutti i Git hosting permettono l’attacco principale. La documentazione ufficiale GitHub sui nomi di branch e tag vieta esplicitamente riferimenti che abbiano l’aspetto di un object ID Git, cioè stringhe di 40 caratteri esadecimali. Un repository GitHub non può quindi creare normalmente il branch che serve alla variante basata sul falso SHA. Questo restringe notevolmente la portata pratica perché i cataloghi predefiniti di numerosi agenti utilizzano repository GitHub. Il vettore diventa invece rilevante per marketplace privati, repository Bitbucket o Git server self-hosted che accettano quel tipo di ref. La distinzione è fondamentale: la vulnerabilità nel client esiste, ma non ogni plugin installato attraverso quei prodotti è automaticamente sfruttabile. Per Gemini CLI Air descrive una variante differente basata su FETCH_HEAD, quindi non direttamente sovrapponibile al trucco del branch denominato come lo SHA. Anche per questo è scorretto trasformare quattro implementazioni vulnerabili in quattro superfici operative perfettamente identiche. La crescita dei plugin rende comunque il problema strutturale. Google ha appena portato plugin interoperabili per Claude Code, Codex e altri coding agent dentro i workflow Google Cloud, aumentando il numero di componenti che possono collegare una workstation direttamente a infrastrutture e identità enterprise.

L’auto-update può trasformare il repository owner in un vettore zero-click

Plugin4Shell diventa particolarmente pericoloso quando il marketplace permette aggiornamenti automatici. Se un plugin precedentemente considerato affidabile viene aggiornato in background e il client non verifica il commit realmente ottenuto, l’utente non deve installare manualmente una nuova release: il repository può cambiare il contenuto servito dietro il riferimento che il sistema continua a considerare approvato. Air Security definisce per questo il problema una zero-click RCE. Anche qui, però, va mantenuta la condizione tecnica: l’aggiornamento automatico deve interessare una sorgente sulla quale il bypass del pin sia effettivamente realizzabile. Nei marketplace predefiniti ospitati su GitHub, la restrizione sui nomi dei ref riduce la praticabilità della variante principale descritta dai ricercatori. Il rischio torna invece elevato negli ambienti enterprise che aggiungono marketplace privati o repository aziendali. Sono proprio questi contesti a concentrare codice proprietario e credenziali ad alto valore. La recente diffusione di Shai-Hulud contro configurazioni Codex, Gemini e altre toolchain AI dimostra inoltre che le workstation degli sviluppatori sono ormai bersagliate anche per i segreti accumulati dagli agenti.

Continua con:

Prompt injection via repository GitHub porta gli agenti AI fino alla reverse shell

GitHub e PyPI introducono difese temporali contro gli attacchi supply chain

La correzione vera è verificare il codice dopo la risoluzione Git

Plugin4Shell mostra perché un pin crittografico non offre alcuna garanzia se il software non verifica l’oggetto ottenuto alla fine della procedura. Per Claude Code e Codex la priorità è quindi utilizzare almeno le versioni indicate come corrette, rispettivamente 2.1.179 e 0.146.0, mentre organizzazioni che utilizzano Copilot o vecchie installazioni Gemini CLI devono valutare le mitigazioni disponibili e soprattutto limitare marketplace esterni non verificati. Negli ambienti aziendali è opportuno censire le sorgenti plugin, evitare repository modificabili da singoli maintainer senza revisione, controllare gli aggiornamenti automatici e separare i privilegi dell’agente dalle credenziali più sensibili. La verifica decisiva rimane quella adottata da OpenAI: dopo il checkout, risolvere il commit reale e confrontarlo con lo SHA approvato, rifiutando qualsiasi divergenza. La lezione supera i quattro prodotti coinvolti. Un marketplace può effettuare review impeccabili, firmare metadati e memorizzare hash corretti, ma se il client trasforma quel riferimento in codice eseguibile senza controllare l’ultimo passaggio, la garanzia di integrità esiste soltanto sulla carta. Con gli agenti AI capaci di operare direttamente su repository, shell, cloud e CI/CD, quel singolo controllo mancante diventa una nuova trust boundary della software supply chain.