Ausgangspunkt der Untersuchung war laut Pillar Security ein automatisierter Agent zur Triage von Pull Requests, der in Pull Requests mit der Rolle „Collaborator“ kommentierte und damit weitreichende Rechte auf dem Repository hatte. Dan Lisichkin fand anschließend einen Weg, diesen Agenten dazu zu bringen, einen Kommentar im Format „@gemini-cli <Eingabeaufforderung>“ in einem Pull Request zu posten. Das löste den Ablauf gemini-invoke aus und öffnete den Zugriff auf einen stärker privilegierten Workflow.

Die erste Eingabeaufforderung führte laut Lisichkin zu einer Antwort aus dem Workflow gemini_invoke.yml, die offenlegte, welche Werkzeuge dem privilegierten Agenten über den MCP-Server zur Verfügung standen. Dabei zeigte sich, dass der Bot auf sämtliche Bash-Befehle zugreifen konnte. Nach Darstellung des Forschers war damit die entfernte Ausführung von Code möglich und potenziell auch das Auslesen des GitHub-Tokens des Agenten.

Lisichkin zufolge ließ sich mit diesem Zugriff die Interaktion anderer Maintainer, Collaborators und Mitglieder beeinflussen. Demnach konnte er Kommentare, Pull Requests und Issues anderer verändern, Reviews verwerfen oder Änderungen an Pull Requests genehmigen sowie gemini-invoke und gemini-review für beliebige Pull Requests auslösen.

Damit war nach Angaben von Pillar Security auch eine Manipulation des Freigabeprozesses für Pull Requests möglich. Für das eigentliche Einschleusen eines bösartigen Pull Requests hätte jedoch weiterhin ein Mitglied den Pull Request genehmigen und zusammenführen müssen. Genau an diesem Punkt wäre Social Engineering nötig gewesen.

Das von Lisichkin beschriebene Szenario sah vor, dass ein Angreifer zunächst Vertrauen als Collaborator aufbaut und dann einen Pull Request mit schädlichem Code einreicht, der zur Prüfung markiert wird. Anschließend könnte derselbe Angreifer einen zweiten Pull Request mit Eingabeaufforderungen eröffnen, die den Agenten anweisen, den ersten Pull Request als triagiert, geprüft und genehmigt zu markieren.

Lisichkin beschreibt die Kette so: Das Bearbeiten des Kommentars des Triage-Agenten nutze die Möglichkeit zur Nachahmung über issues: write; das Posten und Genehmigen als Bot basiere auf dem über entfernte Codeausführung erlangten GITHUB_TOKEN; Änderungen an Labels und Prüfanforderungen fielen unter pull-requests: write. Zusammengenommen entstehe so eine vollständige und glaubwürdige Spur im Stil von „Ein Mensch hat um eine Prüfung gebeten, Gemini hat sie durchgeführt, Gemini hat genehmigt“ für den manipulierten Pull Request, obwohl nichts davon tatsächlich geschehen sei.

Google wurde laut Bericht Anfang Juni über die Entdeckung informiert und behob das Problem durch zusätzliche Härtung. Das Unternehmen bewertete den Befund jedoch nicht als ausreichend für eine Bug-Bounty-Prämie, weil das Zusammenführen des schädlichen Pull Requests Social Engineering vorausgesetzt hätte.

Kurz darauf entdeckte Pillar nach eigenen Angaben eine weitere Schwachstelle im ADK-Repository. Sie betraf die Automatisierungsfunktionen eines auf Antigravity-SDK basierenden Agenten und konnte zu entfernter Codeausführung ohne Interaktion eines Maintainers führen. Google schloss diese Lücke Ende Juli.