>samit_hota
Back to security news

Security News · SN-2026-294

HIGHRESOLVED

Google ADK Vulnerabilities Allowed Agent-to-Agent Prompt Injection and RCE

Affected: Google Agent Development Kit for Python (google/adk-python) · Antigravity-SDK agent automation

Samit Hota·
#news#vulnerability-disclosure#google

Security researchers at Pillar Security have disclosed a critical attack vector in Google’s Agent Development Kit for Python (google/adk-python) that enabled low-privileged AI agents to manipulate privileged agents. The flaw, detailed by researcher Dan Lisichkin, allowed attackers to execute indirect prompt injection attacks against automated agents handling repository triage, exposing internal system secrets, enabling arbitrary command execution, and setting up pull request (PR) poisoning in developer workflows.

As organizations increasingly integrate autonomous AI agents into software development and CI/CD pipelines, agent-to-agent interactions introduce a complex trust boundary problem. When multi-agent systems process untrusted input—such as user-submitted pull requests or issue comments—without proper isolation between administrative and public-facing bots, adversaries can hijack the higher-privileged agent to act as a proxy for malicious commands.

Anatomy of the Agent-to-Agent Attack

The vulnerability stemmed from how Google’s google/adk-python repository deployed automated AI agents with differing privilege levels. The environment maintained two primary classes of agents: low-privileged agents designed to interact with external users during issue and PR triage, and high-privileged agents accessible strictly to maintainers for sensitive tasks.

Pillar Security discovered that an attacker could trigger a privilege escalation sequence by submitting a specially crafted prompt to the public-facing agent. The low-privileged agent, acting on user input, could be coerced into leaving a structured comment on a pull request formatted as @gemini-cli <prompt>.

Because repository automation monitored these comments, this action invoked the gemini-invoke workflow (gemini_invoke.yml), which ran in the context of the privileged maintainer bot. The initial prompt injection caused the high-privileged agent to disclose the internal tools made available to it via its Model Context Protocol (MCP) server.

Among these tools was unrestricted access to bash command execution within the runner environment. By abusing the exposed MCP tool calls, an attacker could execute arbitrary remote code and extract the maintainer agent’s GITHUB_TOKEN.

PR Poisoning and Supply Chain Blast Radius

Once an attacker obtained the privileged GITHUB_TOKEN, the potential blast radius expanded significantly within the target GitHub repository:

  • Impersonation and Comment Modification: Armed with issues: write permissions, the attacker could manipulate comments, issues, and pull request histories belonging to repository maintainers and collaborators.
  • Review Manipulation: Utilizing pull-requests: write permissions, the attacker could dismiss reviews, submit automated approvals, and edit label requests, creating a false audit trail.
  • Automated Workflow Abuse: The extracted token allowed an attacker to programmatically run gemini-invoke and gemini-review actions against any arbitrary pull request in the project.

In a practical attack scenario, a threat actor seeking to poison the software supply chain would first establish baseline trust as an external contributor. The actor would submit a PR containing concealed malicious code, followed by a second PR containing the prompt injection payload. The secondary prompt would instruct the triage agent to mark the initial malicious PR as triaged, reviewed, and approved.

By stringing together the impersonation primitive (issues: write), token extraction via RCE, and review manipulation (pull-requests: write), the attacker creates a fully believable audit trail indicating that a human maintainer requested a review, the Gemini agent conducted it, and the agent approved the changes—without human intervention ever taking place.

While this full chain allowed an attacker to bypass automated controls, Google noted that merging the final malicious PR still required action from an actual repository member, reducing the immediate likelihood of unassisted zero-click supply chain compromise via this specific vector.

Unattended RCE via Antigravity-SDK

Following the initial discovery reported to Google in early June, Pillar Security identified a second, related vulnerability in the ADK repository’s automation features built around the Antigravity-SDK-based agent.

Unlike the initial agent-to-agent prompt injection chain—which required social engineering and human interaction to complete the merge phase—the Antigravity-SDK vulnerability allowed remote code execution without requiring any interaction from repository maintainers. An attacker could trigger execution strictly by feeding input into the automated features of the agent workflow.

Resolution and Hardening

Google addressed both reported issues through hardening measures in the google/adk-python repository. The initial agent-to-agent prompt injection issue was mitigated through stricter input sanitization and workflow permission boundaries after the June disclosure. Google classified the first finding as outside the threshold for a bug bounty reward due to the social engineering required to execute a final code merge, but addressed the secondary Antigravity-SDK RCE vulnerability in late July.

Organizations deploying custom AI agents or adopting the Google Agent Development Kit should review how local MCP tools and elevated GitHub tokens are scoped across automated workflows:

  • Enforce Zero Trust Between Agents: Treat outputs generated by low-privileged AI agents as untrusted user input before passing them downstream to administrative or system-level tools.
  • Restrict Tool Exposure on MCP Servers: Avoid providing generic shell or bash execution tools to LLM agents handling untrusted data streams; limit agent tool sets strictly to atomic, low-risk API endpoints.
  • Isolate CI/CD Automation Tokens: Ensure workflow triggers initiated by public comments or pull requests run in unprivileged execution environments with read-only tokens (contents: read), prohibiting write operations or secret access until explicit maintainer approval is granted.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call