Gemini ADK unter Beschuss: Zwei Schwachstellen enthüllen die Risiken automatisierter KI-Agenten

Am 4. August 2026 hat Pillar Security zwei Schwachstellen im Repository google/adk-python offengelegt, die zeigen, wie ein Angreifer den Lebenszyklus von Pull Requests manipulieren und durch Agenten-Hopping eine Remotecodeausführung erlangen kann. Die an Google gemeldeten Sicherheitslücken betreffen das Agent Development Kit für Python und die Gemini CLI-Erweiterung und lenken den Blick auf die Privilegientrennung zwischen Agenten mit unterschiedlichen Vertrauensstufen.

Eine Prompt-Kette: Vom öffentlichen Kommentar zur Befehlsausführung

Die erste Schwachstelle nutzt die Kommunikation zwischen einem KI-Agenten mit geringen Rechten – dem Triage-Agenten – und den hochprivilegierten Workflows der Maintainer aus. Der Triage-Agent arbeitete mit Collaborator-Berechtigungen und akzeptierte Befehle von jedem GitHub-Nutzer, der einen PR-Kommentar hinterlassen konnte.
Ein Kommentar mit der Syntax @gemini-cli <prompt> genügte, um den Workflow gemini_invoke.yml auszulösen. Darüber wurden über einen MCP-Server alle verfügbaren Werkzeuge bereitgestellt – einschließlich der beliebigen Ausführung von bash-Befehlen.

Jeder konnte so eine Remote-Shell im Kontext des Agenten erlangen. Der nächste Schritt folgte unmittelbar: das GITHUB_TOKEN des Prozesses auszulesen, ein Secret mit Schreibrechten auf Issues, Kommentare, Labels und Reviews. Mit diesem Token ließen sich sämtliche Metadaten einer Pull Request verändern, Reviews genehmigen oder ablehnen und weitere automatisierte Workflows – gemini-invoke und gemini-review – auf beliebige PRs anwenden, auch auf bösartige.

Der kritische Punkt blieb jedoch der tatsächliche Merge des Codes. Dafür ist die Genehmigung eines menschlichen Maintainers erforderlich. Der Forscher konstruierte ein Social-Engineering-Szenario: Mithilfe der Fähigkeit, andere Nutzer zu imitieren (Kommentare in deren Namen zu schreiben) und eine scheinbar „menschliche“ Review-Historie vorzutäuschen, konnte man einem Maintainer vorgaukeln, eine PR sei bereits geprüft und legitim genehmigt worden.

Der zweite Fehler: RCE ohne jede menschliche Interaktion

Nach der ersten Meldung entdeckte Pillar Security einen zweiten Einstiegspunkt in der Automatisierung, die auf Antigravity-SDK basiert, einem Bestandteil des automatischen Agenten. Diese Schwachstelle ermöglichte direkt die Remotecodeausführung, ohne dass ein Maintainer getäuscht werden musste.
Technische Details wurden nicht veröffentlicht, die Schwere jedoch als kritisch eingestuft: Ein Angreifer konnte eine Shell im Kontext des Repositorys erlangen – ohne den Umweg über die PR-Oberfläche und ganz ohne menschliches Zutun.

Google erkannte bei der ersten Lücke keine Bug-Bounty-Berechtigung, weil der bösartige Merge noch einen menschlichen Schritt erforderte. Die zweite veranlasste das Unternehmen zu einer raschen Behebung und einer verstärkten Privilegientrennung zwischen den Agenten.

Warum diese Schwachstellen ein Supply-Chain-Problem sind

Einen unautorisierten Merge auf ein Repository wie google/adk-python zu erzwingen, hätte bedeutet, Schadcode in das von tausenden Python-Projekten genutzte Entwicklerkit einzuschleusen. Ein erfolgreicher Angriff hätte Folgendes ermöglicht:

• Build-Pipelines und Entwicklungsumgebungen zu vergiften.
• Secrets aus anderen Repositories zu stehlen, die von ADK abhängen.
• Die Kompromittierung über verknüpfte Token und Workflows auf interne Google-Dienste auszuweiten.

Selbst wenn der vollständige Exploit noch die Täuschung eines Maintainers erforderte, reichten die Manipulationsmöglichkeiten an Pull Requests aus, um ein glaubwürdiges Szenario zu konstruieren. Der zweite Fehler beseitigte die Notwendigkeit menschlicher Interaktion vollständig.

Was Google unternommen hat und was Entwickler tun müssen

Nach der ersten Meldung hat Google die Privilegientrennung zwischen den Agenten gehärtet. Die zweite Schwachstelle wurde ohne weitere öffentliche Details behoben. Es wurde kein CVE vergeben.

Eine klare Lehre bleibt: Einem KI-Agenten den Zugriff auf Token mit Schreibrechten zu delegieren, ist riskant. Zu den empfohlenen Gegenmaßnahmen gehören:

• Die Privilegien der Agenten auf das absolut Notwendige beschränken.
• Keine Token oder Secrets direkt in automatisierte Workflows geben.
• Interaktionen zwischen Agenten mit unterschiedlichen Rollen überwachen, besonders wenn einer davon unauthentifizierte Befehle akzeptiert.
• Jede Eingabe, die von einem externen Agenten stammt, als nicht vertrauenswürdig behandeln – selbst wenn sie aus dem eigenen CI/CD-Ökosystem kommt.

Der von Pillar Security beschriebene Agent-zu-Agent-Angriff ist kein reines Google-Problem, sondern ein Muster, das sich in jedem Repository wiederholen kann, das KI-Bots mit abgestuften Berechtigungen einsetzt. Mit zunehmender Automatisierung in Entwicklungspipelines wächst die Angriffsfläche – und die Isolierung von Vertrauen wird zur letzten Verteidigungslinie.