Gemini ADK bajo ataque: dos vulnerabilidades revelan los riesgos de los agentes de IA automatizados

El 4 de agosto de 2026, Pillar Security reveló dos fallos en el repositorio google/adk-python que muestran cómo un atacante puede manipular el ciclo de vida de las pull requests y lograr la ejecución remota de código pasando de un agente de IA a otro. Las vulnerabilidades, reportadas a Google, afectan al Agent Development Kit para Python y la extensión Gemini CLI, y advierten sobre el aislamiento de privilegios entre agentes con diferentes niveles de confianza.

Una cadena de prompts: de un comentario público a la ejecución de comandos

El primer fallo explota la comunicación entre un agente de IA de bajo privilegio —el encargado del triaje de pull requests— y los flujos de trabajo de alto privilegio de los mantenedores. El agente de triaje operaba con permisos de Collaborator y aceptaba comandos de cualquier usuario de GitHub que pudiera comentar en una PR.
Bastaba insertar un comentario con la sintaxis @gemini-cli <prompt> para activar el workflow gemini_invoke.yml. Esto exponía las herramientas disponibles a través de un servidor MCP, entre ellas la ejecución arbitraria de comandos bash.

Cualquiera podía obtener así una shell remota en el contexto del agente. El siguiente paso era inmediato: leer el GITHUB_TOKEN del proceso, un secreto con privilegios de escritura sobre issues, comentarios, etiquetas y revisiones. Con ese token, un atacante podía modificar todos los metadatos de una pull request, aprobar o rechazar revisiones, e invocar workflows automatizados adicionales —gemini-invoke y gemini-review— sobre cualquier PR, incluidas las maliciosas.

Sin embargo, la fase crítica seguía siendo el merge efectivo del código. Para ello se requiere la aprobación de un mantenedor humano. El investigador construyó un escenario de ingeniería social: aprovechando la capacidad de suplantar a otros usuarios (escribiendo en su nombre en los comentarios) y de simular un rastro de revisión “humana”, se podía inducir a un mantenedor a creer que una PR ya había sido revisada y aprobada legítimamente.

El segundo bug: RCE sin ninguna interacción humana

Tras el primer informe, Pillar Security descubrió un segundo punto de entrada en la automatización basada en Antigravity-SDK, un componente del agente automático. Esta vulnerabilidad permitía la ejecución remota de código directamente, sin necesidad de engañar a ningún mantenedor.
No se han divulgado los detalles técnicos, pero la gravedad se ha evaluado como crítica: un atacante podía obtener una shell en el contexto del repositorio sin pasar por la interfaz de PR y sin interacción humana alguna.

Google reconoció el primer fallo como no elegible para el bug bounty, ya que el merge malicioso aún requería un paso humano. El segundo, en cambio, llevó a la empresa a corregir rápidamente el problema y a reforzar la separación de privilegios entre los agentes.

Por qué estas vulnerabilidades son un problema de cadena de suministro

Conseguir un merge no autorizado en un repositorio como google/adk-python habría permitido inyectar código malicioso en el kit de desarrollo utilizado por miles de proyectos Python. Un ataque exitoso podría haber:

• Envenenado pipelines de build y entornos de desarrollo.
• Robado secretos de otros repositorios que dependen de ADK.
• Expandido el compromiso a servicios internos de Google mediante tokens y workflows vinculados.

Aunque el exploit completo aún requería engañar a un mantenedor, las capacidades de manipulación de PR eran suficientes para construir un escenario creíble. El segundo bug, en cambio, eliminaba por completo la necesidad de interacción humana.

Qué ha hecho Google y qué deben hacer los desarrolladores

Tras el primer informe, Google aplicó un endurecimiento en la separación de privilegios entre los agentes. La segunda vulnerabilidad fue corregida sin más detalles públicos. No se ha asignado ningún CVE.

Queda una lección clara: delegar el acceso a tokens con poderes de escritura a un agente de IA es un riesgo. Las mitigaciones sugeridas incluyen:

• Limitar los privilegios de los agentes al mínimo indispensable.
• No exponer tokens o secretos directamente a flujos de trabajo automatizados.
• Supervisar las interacciones entre agentes con roles diferentes, especialmente si alguno acepta comandos sin autenticar.
• Tratar cualquier entrada proveniente de un agente externo como no confiable, incluso si procede del propio ecosistema CI/CD.

El ataque agente-contra-agente descrito por Pillar Security no es un problema exclusivo de Google: es un patrón que podría repetirse en cualquier repositorio que utilice bots de IA con privilegios diferenciados. A medida que aumenta la automatización en las pipelines de desarrollo, la superficie de ataque se amplía —y aislar la confianza se convierte en la última línea de defensa.