Gemini ADK sous attaque : deux vulnérabilités révèlent les risques des agents IA automatisés

Le 4 août 2026, Pillar Security a divulgué deux failles dans le dépôt google/adk-python qui montrent comment un attaquant peut manipuler le cycle de vie des pull requests et obtenir une exécution de code à distance en passant d’un agent IA à l’autre. Les vulnérabilités, signalées à Google, concernent l’Agent Development Kit pour Python et l’extension Gemini CLI, et mettent en garde sur l’isolation des privilèges entre des agents ayant des niveaux de confiance différents.

Une chaîne de prompts : d’un commentaire public à l’exécution de commandes

La première faille exploite la communication entre un agent IA à bas privilège — celui qui réalise le triage des pull requests — et les workflows à haut privilège des mainteneurs. L’agent de triage fonctionnait avec des permissions de Collaborateur et acceptait des commandes de n’importe quel utilisateur GitHub en mesure de commenter une PR.
Il suffisait d’insérer un commentaire contenant la syntaxe @gemini-cli <prompt> pour déclencher le workflow gemini_invoke.yml. Celui-ci exposait les outils disponibles via un serveur MCP, dont l’exécution arbitraire de commandes bash.

N’importe qui pouvait ainsi obtenir un shell à distance dans le contexte de l’agent. L’étape suivante était immédiate : lire le GITHUB_TOKEN du processus, un secret disposant de droits d’écriture sur les issues, les commentaires, les étiquettes et les révisions. Avec ce token, un attaquant pouvait modifier chaque métadonnée d’une pull request, approuver ou rejeter des révisions, et invoquer d’autres workflows automatisés — gemini-invoke et gemini-review — sur toute PR, y compris des PR malveillantes.

La phase critique restait néanmoins le merge effectif du code. Pour cela, l’approbation d’un mainteneur humain est nécessaire. Le chercheur a construit un scénario de social engineering : en exploitant la capacité d’usurper d’autres utilisateurs (écrire en leur nom dans les commentaires) et de simuler une trace de révision « humaine », on pouvait amener un mainteneur à croire qu’une PR avait déjà été examinée et approuvée de façon légitime.

Le second bug : RCE sans aucune interaction humaine

Après le premier signalement, Pillar Security a découvert un second point d’entrée dans l’automatisation basée sur Antigravity-SDK, un composant de l’agent automatique. Cette vulnérabilité permettait l’exécution de code à distance directement, sans avoir besoin de tromper un mainteneur.
Les détails techniques n’ont pas été divulgués, mais la gravité a été jugée critique : un attaquant pouvait obtenir un shell dans le contexte du dépôt sans passer par l’interface des PR et sans aucune interaction humaine.

Google a reconnu que la première faille n’était pas éligible au bug bounty, car le merge malveillant exigeait encore une intervention humaine. La seconde, en revanche, a poussé l’entreprise à corriger rapidement le problème et à renforcer la séparation des privilèges entre les agents.

Pourquoi ces vulnérabilités sont un problème de supply chain

Obtenir un merge non autorisé sur un dépôt comme google/adk-python aurait permis d’injecter du code malveillant dans le kit de développement utilisé par des milliers de projets Python. Une attaque réussie aurait pu :

• Empoisonner les pipelines de build et les environnements de développement.
• Voler des secrets depuis d’autres dépôts qui dépendent d’ADK.
• Étendre la compromission à des services internes de Google via des tokens et des workflows liés.

Même si l’exploit complet exigeait encore de tromper un mainteneur, les capacités de manipulation des PR étaient suffisantes pour construire un scénario crédible. Le second bug, lui, supprimait totalement le besoin d’interaction humaine.

Ce qu’a fait Google et ce que doivent faire les développeurs

Après le premier signalement, Google a durci la séparation des privilèges entre les agents. La seconde vulnérabilité a été corrigée sans autres détails publics. Aucun CVE n’a été attribué.

Un enseignement clair demeure : déléguer à un agent IA l’accès à des tokens dotés de pouvoirs d’écriture est un risque. Parmi les mesures d’atténuation suggérées :

• Limiter les privilèges des agents au strict minimum.
• Ne pas exposer directement les tokens ou les secrets aux workflows automatisés.
• Surveiller les interactions entre agents ayant des rôles différents, surtout si l’un d’eux accepte des commandes non authentifiées.
• Considérer toute entrée provenant d’un agent externe comme non fiable, même si elle provient de son propre écosystème CI/CD.

L’attaque agent-à-agent décrite par Pillar Security n’est pas un problème propre à Google : c’est un motif qui pourrait se reproduire dans chaque dépôt utilisant des bots IA avec des privilèges différenciés. Avec l’augmentation de l’automatisation dans les pipelines de développement, la surface d’attaque s’élargit — et isoler la confiance devient la dernière ligne de défense.