Gemini Agent-to-Agent Attack Exposes Security Flaw: Enables Pull Request Tampering

Post Views: 10

Researchers uncovered a critical vulnerability in Google’s Agent Development Kit for Python, enabling unauthorized access and pull request manipulation through agent-to-agent command relaying.

Overview of the Vulnerability

Pillar Security identified a flaw in Google’s Agent Development Kit for Python (google/adk-python repository), allowing attackers to exploit low-privilege AI agents to relay commands to high-privilege agents, bypassing security controls and enabling actions like command execution and supply chain infiltration.

Attack Methodology

The vulnerability stemmed from the interaction between low-privilege agents (accessible to users) and high-privilege agents (restricted to maintainers). Attackers could inject prompts via low-privilege agents, triggering workflows that exposed high-privilege agent capabilities.

Discovery Process

A PR triaging agent was observed commenting on pull requests as a Collaborator, indicating elevated permissions. Researchers discovered that injecting a prompt formatted as @gemini-cli triggered the gemini-invoke workflow, revealing unrestricted bash command execution via the MCP server.

Command Relaying and Exploitation

The workflow exposed tools accessible to high-privilege agents, allowing researchers to execute arbitrary code and extract the agent’s GitHub token. This enabled manipulation of PR comments, issues, reviews, and workflow invocations against any PR.

Response and Resolution

Google was informed in early June and addressed the flaw through enhanced security measures. However, the company did not classify the issue as a bug bounty due to reliance on social engineering for final PR approval. A second vulnerability in the Antigravity-SDK-based agent’s automation features was resolved in late July.

Implications and Recommendations

The attack highlights risks in AI agent architectures, particularly when low-privilege components interact with high-privilege systems. It underscores the need for stricter access controls and monitoring of automated workflows to prevent indirect command relaying bypassing traditional security boundaries.

The attack chain required social engineering to merge malicious code, as final approval still needed a human actor. This involved building trust as a collaborator, submitting a PR with malicious code, and creating a second PR to manipulate the agent into marking the first as triaged and approved, generating a fabricated audit trail.