Vulnerabilidad en los flujos de trabajo de ADK
Google ha eliminado tres flujos de trabajo de agentes de IA de su repositorio de Python para el Agent Development Kit (ADK) tras una investigación de Pillar Security. Los investigadores demostraron que un problema público en GitHub podía inyectar instrucciones maliciosas en un agente de triaje, lo que a su vez podía activar un agente privilegiado de corrección de código.
El ataque se basaba en que un comentario público generado por el agente de triaje, manipulado mediante prompt injection, incluía el comando "/adk-issue-fix" como si lo hubiera publicado el bot "adk-bot". Dado que el bot era colaborador del repositorio, ese comentario cumplía el requisito de autorización (propietario, miembro o colaborador) del flujo de trabajo privilegiado, utilizando la identidad confiable del bot como puente de autorización.
Los investigadores lograron ejecutar código arbitrario en el runner de integración continua (CI) y exfiltrar el token de acceso personal (PAT) del bot. Además, el trabajo privilegiado contenía una clave API de Google y una credencial de cuenta de servicio de Google Cloud. Cabe destacar que los ataques de prueba de concepto controlados por los investigadores no identifican explotación en la naturaleza ni una versión comprometida de ADK.
La vulnerabilidad residía en la automatización del repositorio, no en el paquete ADK distribuido. Para repositorios similares, Pillar recomienda utilizar identidades de bot separadas, limitar los alcances de tokens y herramientas, y emplear una señal de autorización que no pueda ser generada por texto no confiable.
El flujo de ataque comenzaba en el flujo de trabajo público "issue-analyze.yml", que se ejecutaba automáticamente al abrir un problema. Este se autenticaba con ADK_GCP_SA_KEY, proporcionaba ADK_TRIAGE_AGENT y GOOGLE_API_KEY al agente de codificación Antigravity de Google, y publicaba el análisis generado como comentario usando la cuenta del bot.
Otro flujo de trabajo, "issue-fix.yml", escuchaba los comentarios con "/adk-issue-fix" y restringía su ejecución a propietarios, miembros o colaboradores. El control verificaba quién publicaba el comando, no si un externo había manipulado la cuenta confiable detrás de él.
El trabajo privilegiado declaraba acceso de escritura a problemas, contenido del repositorio y solicitudes de extracción. Sin embargo, esos ajustes se aplicaban al GITHUB_TOKEN generado por GitHub, no al PAT del agente ADK_TRIAGE_AGENT que realmente se usaba. Según Pillar, los alcances exactos del PAT no eran públicos. El trabajo hacía checkout del repositorio con el PAT, se autenticaba en Google Cloud y ejecutaba el agente con el PAT y la clave API en su entorno. El flujo estaba diseñado para editar código, crear un fork de adk-bot, subir una rama y abrir una solicitud de extracción. Una solicitud de extracción generada por el bot con fecha del 4 de junio muestra que la automatización estaba operando en el repositorio.
El runner rechazaba metacaracteres de shell y solo permitía comandos cuyo primer token fuera "gh" o "git". Pero el script habilitaba CapabilitiesConfig(), que según la documentación del SDK Antigravity de Google activa todas las herramientas, incluida la escritura. El agente podía escribir un payload y hacer que un comando Git permitido lo ejecutara a través de una ruta de hook personalizada. La documentación de Git confirma que los hooks son programas ejecutables y que core.hooksPath puede redirigir Git a otro directorio. La lista de comandos permitidos limitaba la sintaxis, pero la escritura de archivos y Git aún dejaban una vía para la ejecución de código.
Los artefactos públicos no establecen si el PAT podía hacer push directo a la rama principal. Pillar indicó que Google le informó que la cuenta de servicio tenía acceso a Vertex AI en un proyecto dedicado de gestión de GitHub; no se revelaron permisos más amplios. El informe de Pillar describe la ejecución en el runner y la exposición de credenciales, pero el registro público no establece el alcance posterior de esas credenciales en el repositorio o la nube.
El informe también describía una cadena anterior que podía crear una falsa pista de revisión mediante flujos de trabajo privilegiados de Gemini, aunque un mantenedor aún tenía que fusionar la solicitud de extracción.
El commit de eliminación de Google indica que los flujos de trabajo procesaban contenido no confiable de problemas y solicitudes de extracción con credenciales amplias del repositorio. Google eliminó issue-analyze.yml, issue-fix.yml y pr-analyze.yml en un parche cuya metadatos llevan fecha de autor del 9 de junio de 2026. Pillar verificó que los flujos de trabajo estaban ausentes el 2 de julio y que Google confirmó la corrección el 21 de julio. Una verificación de The Hacker News el 4 de agosto de 2026 no encontró ninguno de los tres archivos en el directorio de flujos de trabajo de la rama principal actual.
