Gemini ADK sotto attacco: due vulnerabilità svelano i rischi degli agenti AI automatizzati

Il 4 agosto 2026, Pillar Security ha reso note due falle nel repository google/adk-python che mostrano come un attaccante possa manipolare il ciclo di vita delle pull request e ottenere l’esecuzione remota di codice passando da un agente AI all’altro. Le vulnerabilità, segnalate a Google, riguardano l’Agent Development Kit per Python e l’estensione Gemini CLI, e mettono in guardia sull’isolamento dei privilegi tra agenti con differenti livelli di fiducia.

Una catena di prompt: da un commento pubblico all’esecuzione comandi

La prima falla sfrutta la comunicazione tra un agente AI a basso privilegio — quello che esegue il triage delle pull request — e i workflow ad alto privilegio dei manutentori. L’agente di triage operava con permessi da Collaborator e accettava comandi da qualsiasi utente GitHub in grado di commentare una PR.
Bastava inserire un commento con la sintassi @gemini-cli <prompt> per attivare il workflow gemini_invoke.yml. Questo esponeva i tool disponibili attraverso un server MCP, tra cui l’esecuzione arbitraria di comandi bash.

Chiunque poteva quindi ottenere una shell remota nel contesto dell’agente. Il passo successivo era immediato: leggere il GITHUB_TOKEN del processo, un segreto con privilegi di scrittura su issue, commenti, etichette e revisioni. Con quel token, un attaccante poteva modificare ogni metadato di una pull request, approvare o respingere revisioni, e invocare ulteriori workflow automatizzati — gemini-invoke e gemini-review — su qualsiasi PR, incluse quelle malevole.

La fase critica restava però il merge effettivo del codice. Per quello serve l’approvazione di un manutentore umano. Il ricercatore ha costruito uno scenario di social engineering: sfruttando la capacità di impersonare altri utenti (scrivendo a nome loro nei commenti) e di simulare una traccia di revisione “umana”, si poteva indurre un manutentore a credere che una PR fosse già stata vagliata e approvata legittimamente.

Il secondo bug: RCE senza alcuna interazione umana

Dopo la prima segnalazione, Pillar Security ha scoperto un secondo punto di ingresso nell’automazione basata su Antigravity-SDK, un componente dell’agente automatico. Questa vulnerabilità consentiva l’esecuzione remota di codice direttamente, senza bisogno di ingannare alcun manutentore.
Non sono stati divulgati i dettagli tecnici, ma la gravità è stata valutata critica: un attaccante poteva ottenere una shell nel contesto del repository senza passare per l’interfaccia delle PR e senza alcuna interazione umana.

Google ha riconosciuto la prima falla come non eleggibile per il bug bounty, perché il merge malevolo richiedeva ancora un passo umano. La seconda, invece, ha spinto l’azienda a correggere rapidamente il problema e a rafforzare la separazione dei privilegi tra gli agenti.

Perché queste vulnerabilità sono un problema di supply chain

Ottenere un merge non autorizzato su un repository come google/adk-python avrebbe permesso di iniettare codice malevolo nel kit di sviluppo utilizzato da migliaia di progetti Python. Un attacco riuscito avrebbe potuto:

• Avvelenare pipeline di build e ambienti di sviluppo.
• Rubare segreti da altri repository che dipendono da ADK.
• Espandere la compromissione a servizi interni Google attraverso token e workflow collegati.

Anche se l’exploit completo richiedeva ancora l’inganno di un manutentore, le capacità di manipolazione delle PR erano sufficienti per costruire uno scenario credibile. Il secondo bug, invece, eliminava del tutto la necessità di interazione umana.

Cosa ha fatto Google e cosa devono fare gli sviluppatori

Dopo la prima segnalazione, Google ha applicato un hardening alla separazione dei privilegi tra gli agenti. La seconda vulnerabilità è stata corretta senza ulteriori dettagli pubblici. Nessun CVE è stato assegnato.

Resta un insegnamento netto: delegare a un agente AI l’accesso a token con poteri di scrittura è un rischio. Le mitigazioni suggerite includono:

• Limitare i privilegi degli agenti al minimo indispensabile.
• Non esporre token o segreti a workflow automatizzati in modo diretto.
• Monitorare le interazioni tra agenti con ruoli diversi, specialmente se uno di essi accetta comandi non autenticati.
• Trattare qualsiasi input proveniente da un agente esterno come non affidabile, anche se arriva dal proprio ecosistema CI/CD.

L’attacco agent-to-agent descritto da Pillar Security non è un problema solo di Google: è un pattern che potrebbe ripetersi in ogni repository che utilizza bot AI con privilegi differenziati. Con l’aumento dell’automazione nelle pipeline di sviluppo, la superficie d’attacco si allarga — e isolare la fiducia diventa l’ultima linea di difesa.