Google a supprimé trois workflows ADK de son dépôt Python Agent Development Kit (ADK). La décision fait suite à une démonstration de Pillar Security montrant qu’un issue public sur GitHub pouvait être utilisé pour “orienter” un agent de triage vers un agent de correction de code disposant de privilèges élevés.
Le point clé de l’affaire n’est pas une faille dans la bibliothèque Python distribuée elle-même, mais dans l’automatisation du dépôt : la façon dont les workflows GitHub déclenchent des actions et relaient des commandes vers des identités ou jetons censées rester sous contrôle.
Ce que Pillar Security a montré avec l’issue public
Les chercheurs décrivent un scénario où un contenu injecté dans une demande publique pourrait être interprété par l’agent de triage. L’objectif serait de pousser l’agent à publier une commande de type /adk-issue-fix, puis à faire en sorte que GitHub l’enregistre sous une forme associée au compte de bot (adk-bot).
Une fois cette étape franchie, la logique de permission du workflow “fix” peut être trompée. En pratique, la vérification se concentre sur qui poste la commande (l’identité du bot considérée comme autorisée), et non sur si le texte ou l’ordre a été manipulé en amont par une source non fiable.
Un chaînage d’agents menant à des privilèges plus élevés
Le dispositif en cause implique deux workflows distincts. D’abord, issue-analyze.yml se lance automatiquement lors de l’ouverture d’un issue. Ensuite, issue-fix.yml surveille les commentaires contenant la commande attendue, et exécute un job privilégié si l’auteur correspond à des rôles autorisés (owner, member ou collaborator).
Selon Pillar, l’enchaînement a permis à un agent d’exécuter des actions avec un niveau d’accès que le modèle de sécurité visait à limiter. Le job privilégié détenait notamment :
- une clé Google API ;
- des informations d’identification de type service-account Google Cloud ;
- et un Personal Access Token (PAT) utilisé dans l’exécution.
Les chercheurs indiquent avoir démontré une exécution arbitraire de code sur le runner d’intégration continue (CI), ainsi que l’exfiltration du PAT du bot.
Ils précisent également que leur démonstration ne prouve pas, à ce stade, l’existence d’une exploitation observée dans la nature, ni la compromission d’une version publiée d’ADK.
Pourquoi l’automatisation du dépôt a posé problème
Pillar insiste sur un point : le composant exposé serait l’automatisation du dépôt, pas un défaut dans la manière dont la bibliothèque ADK est “packagée” ou consommée par les développeurs.
Dans ce contexte, plusieurs recommandations sont mises en avant pour limiter la surface d’attaque sur des dépôts similaires :
- utiliser des identités de bot séparées pour les différentes étapes ;
- réduire au minimum les portées de jetons et les droits d’outils ;
- ne pas faire dépendre une autorisation sensible d’un signal que du texte non fiable pourrait influencer.
Autrement dit, même si l’idée générale de “ne lancer le job que pour certains auteurs” est logique, le mécanisme a pu être contourné parce que l’authentification du bot a servi de passerelle à l’autorisation.
Le chemin d’attaque : de issue-analyze à issue-fix
D’après les éléments décrits, l’attaque débute dans le workflow issue-analyze.yml. Ce workflow s’exécute automatiquement à l’ouverture d’un issue et s’appuie sur des éléments d’environnement liés à ADK, notamment :
- un identifiant ADK_GCP_SA_KEY pour l’accès à Google Cloud ;
- des paramètres alimentant un agent de codage “antigravity” ;
- et une Google API key fournie au processus.
Le workflow publie ensuite l’analyse générée sous forme de commentaire via le compte de bot.
Le second workflow, issue-fix.yml, réagit aux commentaires contenant la commande de correction. Le “contrôle d’accès” s’appuie alors sur l’identité de l’auteur du commentaire, ce qui devient problématique si cette identité peut être atteinte via des étapes précédentes manipulées.
Jetons, scopes et exécution sur le runner
Le job privilégié déclare notamment des droits d’écriture sur les issues, le contenu du dépôt et les pull requests. L’un des détails rapportés est que ces permissions concernent le GITHUB_TOKEN généré par GitHub, alors que le job utilise effectivement un PAT associé au bot pour agir.
Les chercheurs notent aussi que les scopes exacts du PAT ne sont pas publics. Le workflow vérifierait le dépôt, s’authentifierait auprès de Google Cloud, puis lancerait l’agent avec, dans l’environnement, le PAT et la clé API.
Le fonctionnement décrit est orienté vers la modification de code : création de branche, éventuel fork de type adk-bot, puis ouverture d’une pull request.
Pillar mentionne également un signe d’activité : une pull request générée par le bot datée du 4 juin indiquait que l’automatisation était opérationnelle dans le dépôt.
“Allowlist” de commandes : une protection contournable
Un point technique important concerne la manière dont le runner encadre les commandes. Le système de validation rejetait certains métacaractères shell et ne laissait passer que des commandes dont le premier token commence par gh ou git.
Cependant, la logique permettait d’activer des capacités plus larges via une configuration côté SDK : le système pouvait activer tous les outils (writes incluses) selon la documentation du SDK antigravity citée par Pillar. L’agent aurait alors pu écrire un contenu malveillant, puis déclencher une exécution via un mécanisme compatible avec les contraintes autorisées.
Les chercheurs relient cette possibilité à la mécanique de Git hooks. La documentation Git indique que les hooks sont des programmes exécutables et que la propriété core.hooksPath peut rediriger Git vers un autre répertoire. Même si l’allowlist réduit certains formats de commande, des écritures sur le système de fichiers et l’usage de Git laissent potentiellement une voie vers l’exécution.
Ce que les preuves publiques établissent (et n’établissent pas)
Les éléments publics rapportés ne prouvent pas de manière exhaustive que le PAT pouvait pousser directement vers la branche principale. Pillar indique toutefois avoir reçu une confirmation de Google sur l’existence d’un accès Vertex AI via un projet dédié à la gestion GitHub, tout en précisant que les permissions plus larges n’ont pas été détaillées publiquement.
En d’autres termes, le rapport documente l’exécution sur le runner et l’accès aux identifiants, mais la portée “aval” exacte (par exemple les dépôts ou services atteignables ensuite) n’est pas complètement établie dans les informations rendues publiques.
Suppression des workflows et état du dépôt
Google a supprimé issue-analyze.yml, issue-fix.yml et pr-analyze.yml. Le commit de retrait mentionne que les workflows traitaient du contenu d’issues et de pull requests comme entrées non fiables, tout en utilisant des identifiants de dépôt aux privilèges étendus.
Selon Pillar, les équipes ont vérifié que les workflows étaient absents le 2 juillet, et que Google a ensuite confirmé la correction le 21 juillet. De son côté, The Hacker News indique qu’au 4 août 2026, aucun des trois noms de fichiers ne figurait dans le répertoire des workflows “main”.
Une réponse attendue de Google et de Pillar
The Hacker News a contacté Google au sujet des scopes du jeton du bot, des permissions du service-account, et des éléments de preuve liés à l’exploitation. L’équipe a aussi sollicité Pillar Security au sujet de l’environnement de preuve de concept et de l’accès aux identifiants. Au moment de la rédaction, ces réponses étaient en attente.
Conclusion : leçons de sécurité autour des workflows ADK
Cette affaire met en lumière une réalité fréquente en sécurité applicative : ce n’est pas seulement le code “lui-même” qui peut poser problème, mais aussi les automatisations qui orchestrent l’exécution et relaient des signaux d’autorisation.
En supprimant les workflows ADK concernés, Google répond à un risque décrit comme exploitable via une manipulation d’issues publiques, avec impact sur l’exécution CI et l’accès à des jetons. Pour les équipes qui développent des dépôts avec agents IA, la recommandation centrale reste la même : cloisonner les identités, limiter strictement les droits et ne jamais laisser le texte non fiable servir de base à des décisions d’autorisation sensibles.
Source: https://thehackernews.com/2026/08/google-deletes-3-adk-ai-workflows-after.html
