Google hat drei ADK-AI-Workflows aus dem Agent Development Kit (ADK) Python-Repository entfernt. Anlass war ein Bericht von Pillar Security, der beschreibt, wie eine öffentlich sichtbare GitHub-Meldung einen internen Prüf- bzw. Triage-Agenten dazu bringen konnte, eine privilegierte Code-Korrektur-Automation auszulösen.
Die Besonderheit: Der Angriff lief nicht über eine Schwachstelle im eigentlichen ADK-Paket, sondern über die Repository-Automatisierung. Dadurch konnten untrusted Inhalte indirekt als „vertrauenswürdig“ durch ein Bot-Identitäts-Prüfsignal wirken.
Was Google an den ADK-AI-Workflows geändert hat
Google löschte laut den verfügbaren Informationen die Workflows issue-analyze.yml, issue-fix.yml und pr-analyze.yml. In einem entsprechenden Commit werden Workflows entfernt, die untrusted Inhalte aus Issues oder Pull Requests verarbeiten – und dabei mit breiteren Repository- bzw. Token-Berechtigungen kombiniert waren.
Zum Zeitpunkt der Untersuchung bestätigte Pillar Security, dass die Workflows bis Anfang Juli nicht mehr vorhanden waren. Später meldete Google außerdem, dass ein gemeldeter Issue-Fix als abgeschlossen gilt.
Der Kern des Problems: Prompt Injection + Bot-Identität
Die Forschenden zeigten einen Angriffsweg, bei dem ein öffentlicher Bot-gestützter Prozess manipuliert werden konnte. Der Ausgangspunkt war ein Workflow, der automatisch bei neuen Issues startet: issue-analyze.yml.
Die öffentliche Issue konnte so präpariert werden, dass der Triage-Agent in eine bestimmte Kommentarfunktion hineingezogen wurde. Dabei sollte offenbar ein Kommando erzeugt werden, das später als Trigger für den privilegierten Fix-Workflow dient.
Entscheidend war, wie die Autorisierung im Folge-Workflow ablief: Der Workflow issue-fix.yml prüfte dem Bericht zufolge, ob der auslösende Kommentar von einem zulässigen Absender stammt (Owner, Member oder Collaborator) – aber nicht, ob ein Außenstehender den vertrauenswürdigen Bot-Kontext über einen Manipulationspfad ausnutzen konnte.
Mit anderen Worten: Wenn die Aktion so „zurechtgebogen“ werden konnte, dass ein Kommentar so erschien, als käme er von einem als Kollaborateur erkannten Bot, wurde die Gate-Logik „übersprungen“. Der Bot selbst wurde damit zur Art Autorisierungsbrücke.
Welche Privilegien im Spiel waren
Im privilegierten Teil des Ablaufs wurde ein Job gestartet, der sehr weitreichende Schreibrechte benötigte. Laut Bericht bezogen sich diese Einstellungen auf GitHub-seitig generierte Berechtigungen für den GITHUB_TOKEN – während das tatsächlich verwendete ADK-Funktionselement mit einem anderen Token arbeitete, nämlich mit dem ADK_TRIAGE_AGENT-Token (PAT) und zusätzlichen API- und Schlüsselmaterialien aus der Umgebung.
Auf der Cloud-Seite zeigte Pillar, dass im Job auch ein Google API Key sowie eine Google Cloud Service-Account-Zuordnung (Credential) vorhanden waren. Damit konnten im Angriffsszenario nicht nur Agenten-Outputs erzeugt, sondern auch operative Schritte auf dem CI-Runner angestoßen werden.
Beobachtete Auswirkungen: Codeausführung und Token-Exfiltration
Die Forschenden berichten, dass sie im PoC-Umfeld beliebige Codeausführung auf dem CI-Runner demonstrieren konnten. Zusätzlich führten sie eine Exfiltration des Bot-Personal-Access-Tokens (PAT) durch.
Wichtig ist dabei die Einschränkung aus dem Bericht: Die öffentliche Evidenz belegt keine Ausnutzung „in freier Wildbahn“ und keinen kompromittierten ADK-Release. Die Details deuten vielmehr darauf, dass das Risiko besonders bei vergleichbaren Repository-Automationen mit ähnlichen Musterkombinationen relevant ist.
Warum die Repository-Automation gefährlich war (nicht das ADK-Paket)
Pillar Security stellt klar, dass der kritische Baustein nicht als Fehler im verteilten ADK-Python-Paket eingeordnet werden sollte, sondern in der Automation innerhalb des Repositories. Genau dort entscheidet sich, wie Tokens bereitgestellt, Befehle interpretiert und Autorisierungsentscheidungen getroffen werden.
Für ähnliche Setups empfiehlt Pillar, separate Bot-Identitäten zu verwenden, die jeweils nur die minimal nötigen Rechte besitzen. Außerdem sollte man die Token- und Tool-Scope enger fassen und sicherstellen, dass untrusted Text keine Autorisierungssignale erzeugen kann.
So lief der Angriff technisch ab
Der beschriebene Pfad begann in issue-analyze.yml. Dieser Workflow lief automatisch, sobald ein Issue eröffnet wurde, und authentifizierte sich dabei unter anderem mit ADK_GCP_SA_KEY. Zudem wurden Variablen wie ADK_TRIAGE_AGENT und GOOGLE_API_KEY an den Coding-Agenten übergeben, der als „Antigravity“-Coding-Agent beschrieben wird. Das Ergebnis wurde anschließend als Kommentar über das Bot-Konto veröffentlicht.
Der zweite Workflow, issue-fix.yml, hörte auf Kommentare mit einer bestimmten Kommandozeile, konkret auf den Trigger /adk-issue-fix. Die Ausführung wurde dabei über eine Gate-Logik beschränkt, die sich am „Wer hat kommentiert?“ orientierte.
Im privilegierten Job war außerdem vorgesehen, Code zu verändern, einen Fork für den Bot zu erzeugen, einen Branch zu pushen und schließlich einen Pull Request zu eröffnen. Ein bot-generierter Pull Request aus dem frühen Juni zeigt laut Bericht, dass die Automation in der Vergangenheit bereits „normal“ im Repository aktiv sein konnte.
Runner-Schutzmaßnahmen reichten nicht aus
Der Runner wurde so beschrieben, dass bestimmte Shell-Metazeichen blockiert wurden und nur Kommandos zugelassen waren, deren erstes Token gh oder git
Allerdings wird im Bericht genannt, dass das Skript eine Konfiguration aktivierte, die laut Dokumentation des Antigravity SDK alle Tools einschalten kann – inklusive Schreiboperationen. Dadurch blieb ein Weg, um einen Payload zu platzieren und über eine Git-Strategie auszuführen.
Git unterstützt Hooks als ausführbare Programme. Der Bericht verweist darauf, dass Konfigurationen wie core.hooksPath genutzt werden können, um Git auf ein anderes Hook-Verzeichnis umzuleiten. Selbst wenn der Allowlist-Ansatz die erlaubte Befehlssignatur enger fasst, können Dateischreib- und Git-Funktionalitäten weiterhin eine Route zur Codeausführung eröffnen.
Keine endgültige Aussage zur Reichweite der Credentials
Ein Teil der Bewertung ist bewusst zurückhaltend: Öffentliche Artefakte belegen nicht, ob der PAT direkt in der Lage war, Änderungen in einen Main-Branch zu pushen. Pillar sagt jedoch, dass Google Informationen zur Rolle des Service-Accounts gab, darunter eine Vertex-AI-Verbindung in einem dedizierten GitHub-Management-Kontext. Weitergehende Berechtigungen seien nicht vollständig offengelegt worden.
Auch wenn der Bericht Runner-Ausführung und Credential-Zugriff beschreibt, lässt sich aus dem öffentlichen Stand nicht eindeutig ableiten, wie weit sich die Credentials „downstream“ im Ziel-Ökosystem auswirken könnten.
Weitere Ketten: mögliche Manipulation von Review-Spuren
Der Bericht beschreibt zudem eine frühere Kette, die in Richtung einer verfälschten Review-Historie über privilegierte Gemini-Workflows gehen konnte. Dabei wird jedoch betont, dass ein Maintainer den Pull Request weiterhin manuell hätte zusammenführen müssen – das Risiko bewegte sich also weniger im Bereich „automatische Endgültigkeit“, sondern stärker in der Richtung „scheinbar legitime Spuren“.
Warum Googles Reaktion wichtig ist
Mit der Löschung der betroffenen Workflows setzt Google ein deutliches Signal: Wenn untrusted Inhalte direkt oder indirekt an privilegierte Agenten- oder CI-Schritte gekoppelt sind, müssen solche Automatismen mit konservativen Sicherheitsannahmen neu gestaltet werden.
Der konkrete Fall zeigt vor allem, wie schnell sich ein Security-Gap aus einer Kombination mehrerer Faktoren ergibt: öffentliche Inhalte, Prompt-Injection-Pfade, Bot-Identitäten als „Gate“, sowie Token und Tools, die im Job zu weitreichend sind.
Fazit
Google hat drei ADK-AI-Workflows aus dem ADK-Repository gelöscht, nachdem Pillar Security gezeigt hat, wie eine öffentliche GitHub-Meldung einen privilegierten Code-Fix-Agenten auslösen konnte. Der Angriff beruhte auf der Manipulierbarkeit von Autorisierungssignalen über Bot-Kommentare, ergänzt durch Möglichkeiten zur Codeausführung im CI-Umfeld und die Exfiltration eines Bot-PAT.
Für Betreiber ähnlicher Repositories ist die Kernbotschaft klar: Nutze getrennte Bot-Identitäten, reduziere Token-Scope, halte Autorisierung von untrusted Text fern und prüfe die gesamte Automationskette – nicht nur einzelne Bibliotheken.
Quelle: https://thehackernews.com/2026/08/google-deletes-3-adk-ai-workflows-after.html
