Gemini CLI CVSS 10: GitHub-RCE durch TrustIssues und Prompt Injection

Gemini CLI und die GitHub Action run-gemini-cli hatten eine der heikelsten Schwachstellen, die bisher bei AI-Coding-Agenten öffentlich beschrieben wurde: In bestimmten CI/CD-Setups konnte ein externer Angreifer aus untrusted Inhalt heraus Remote Code Execution auf dem Runner erreichen. Google behandelt den Fall unter GHSA-wpqr-6v78-jr5g; die Advisory bewertet das Risiko mit CVSS 10.0 Critical.

Wichtig für die Einordnung: Das ist kein „das Modell hat halluziniert”-Vorfall. Die Schwachstelle lag im Trust-Modell rund um agentische Automatisierung: Welche Dateien darf ein Agent laden? Welche Tools darf er ausführen? Welche Tokens liegen im Runner? Und darf ein öffentliches GitHub Issue faktisch einen Agenten mit Shell-Zugriff fernsteuern?

Was ist passiert?

Hackread fasst den jüngsten Forschungsstand so zusammen: Pillar Security zeigte, dass ein Angreifer über ein öffentliches GitHub Issue eine Gemini-gestützte Triage-Automation beeinflussen konnte. Das Issue war untrusted Input, wurde aber vom Agenten gelesen und verarbeitet. In der betroffenen Konfiguration lief Gemini CLI im --yolo-Modus, also mit automatischer Freigabe von Tool-Aufrufen.

Pillar nennt diese Angriffsklasse TrustIssues. Der Pfad war nicht nur „Prompt Injection führt zu einem falschen Label”, sondern konnte in der Proof-of-Concept-Kette bis zur Übernahme des google-gemini/gemini-cli-Repositorys eskalieren. Der Grund: Der Agent konnte sensible Runner-Daten lesen, der Workflow hatte nutzbare GitHub-Berechtigungen, und Credentials waren trotz gut gemeinter Environment-Isolation noch über den Workspace erreichbar.

Parallel beschreibt Novee Security die zweite zentrale Ursache: In älteren Versionen vertraute Gemini CLI in Headless- und CI-Umgebungen Workspace-Ordnern automatisch. Dadurch konnten lokale Konfigurationen, etwa in .gemini/ oder .env, geladen werden, bevor ein Mensch das Projekt als vertrauenswürdig bestätigt. Bei untrusted Pull Requests ist genau das ein RCE-Designfehler.

Betroffene Versionen und Patches

Die offiziellen Fixes sind seit dem 24. April 2026 verfügbar. Laut Advisory sind diese Versionen relevant:

• Betroffen: @google/gemini-cli vor 0.39.1.
• Betroffen: @google/gemini-cli in der 0.40-Preview vor 0.40.0-preview.3.
• Betroffen: google-github-actions/run-gemini-cli vor 0.1.22.
• Gepatcht: @google/gemini-cli 0.39.1, @google/gemini-cli 0.40.0-preview.3 und run-gemini-cli 0.1.22.

Besonders leicht zu übersehen sind gepinnte Versionen. Die GitHub Action kann zwar standardmäßig die aktuelle Gemini-CLI-Version beziehen, aber Workflows mit explizitem gemini_cli_version bleiben auf der gewählten Version stehen. Genau solche Pins sollten jetzt aktiv gesucht und bewertet werden.

Die TrustIssues-Angriffskette

Die Pillar-Kette ist deshalb lehrreich, weil sie zeigt, wie ein scheinbar harmloser Automations-Use-Case kippt. Ein Repository will Issues automatisch labeln. Ein externer Nutzer öffnet ein Issue. Der AI-Agent liest den Text, darf Shell- oder GitHub-CLI-Werkzeuge nutzen und schreibt anschließend ein Label oder eine Antwort. Das klingt nach Produktivität; sicherheitlich ist es aber ein Agent mit Zugriff auf untrusted Text, Runner-Dateisystem und Kommunikationskanäle.

In der konkreten Analyse war ein wichtiger Punkt, dass der GITHUB_TOKEN nicht an den Gemini-Schritt übergeben wurde. Diese Maßnahme war sinnvoll, aber unvollständig. actions/checkout speichert Credentials standardmäßig im Git-Remote des ausgecheckten Repositorys, sofern persist-credentials nicht deaktiviert ist. Ein Agent mit Dateizugriff konnte dadurch trotzdem an nutzbare Tokens kommen.

Danach wurde es zum Berechtigungsproblem: Ein Token mit actions: write kann andere Workflows starten. Wenn ein nachgelagerter Workflow großzügigere Rechte wie contents: write besitzt und vom Angreifer kontrollierte Refs verarbeitet, entsteht aus einem Issue-Triage-Agenten eine realistische Supply-Chain-Kette. Nicht der erste Token ist entscheidend, sondern der Weg zu einem mächtigeren Token.

Workspace Trust im Headless-Modus

Der zweite Teil der Advisory betrifft die Frage, ob ein Projektordner als vertrauenswürdig gilt. Interaktive Developer-Tools können Nutzer fragen: „Vertraust du diesem Workspace?” In Headless-Umgebungen gibt es keinen Klick. Ältere Gemini-CLI-Versionen lösten das zu bequem und vertrauten CI-Workspaces automatisch für Konfigurations- und Environment-Ladevorgänge.

Die gepatchte Logik zieht Headless-Verhalten näher an das interaktive Sicherheitsmodell heran: Ohne explizite Vertrauensentscheidung werden Workspace Settings, lokale .env-Dateien und riskante Automatisierungsfunktionen eingeschränkt. Die Trusted-Folders-Dokumentation beschreibt diesen Safe Mode als Schutz vor gefährlichen lokalen Projektkonfigurationen.

Warum --yolo besonders gefährlich war

--yolo ist für Automatisierung verlockend, weil der Agent nicht bei jedem Tool-Aufruf auf menschliche Zustimmung wartet. In der verwundbaren Variante ignorierte dieser Modus jedoch feingranulare Tool-Allowlisten. Ein Workflow konnte also scheinbar nur run_shell_command(echo) erlauben, während --yolo praktisch beliebige Shell-Kommandos freigab.

Der Patch erzwingt Tool-Allowlisting nun auch unter --yolo. Das ist wichtig, aber keine Einladung, untrusted Inhalte mit breiten Shell-Rechten zu verarbeiten. Eine Allowlist ist nur so gut wie ihre Einträge: Wer cat, curl, bash oder zu breite Shell-Patterns erlaubt, schafft weiterhin Exfiltrations- und Ausführungspfade.

Sofortmaßnahmen für Teams

Wer Gemini CLI oder run-gemini-cli in GitHub Actions nutzt, sollte nicht nur updaten, sondern das gesamte Agenten-Setup als privilegierten Codepfad behandeln.

# Schnellcheck im Repository: Wo tauchen Gemini CLI und riskante Modi auf?
rg "run-gemini-cli|@google/gemini-cli|gemini_cli_version|--yolo|GEMINI_TRUST_WORKSPACE" .github package.json package-lock.json pnpm-lock.yaml yarn.lock

# Beispiel für untrusted Workflows: Credentials nicht in .git/config persistieren
- uses: actions/checkout@v4
  with:
    persist-credentials: false

# Workspace-Trust nur bei wirklich vertrauenswürdigen Inputs setzen
env:
  GEMINI_TRUST_WORKSPACE: "true"

Welche Umgebungen zuerst prüfen?

Die höchste Priorität haben Workflows, bei denen ein externer Nutzer den Input des Agenten beeinflussen kann. Dazu gehören Issue-Triage, Pull-Request-Reviews, Kommentar-Trigger wie @gemini-cli, Verarbeitung von Forks und alle Jobs, die Repository-Inhalte aus fremden Branches analysieren. Je mehr Secrets, OIDC-Rechte und GitHub-Token-Rechte im selben Job verfügbar sind, desto höher ist die Dringlichkeit.

Niedriger, aber nicht irrelevant, sind rein interne Workflows mit Gemini CLI. Auch dort sollten Tool-Allowlists, Workspace Trust und Token-Rechte sauber dokumentiert sein. Interne Angreifer, kompromittierte Developer Accounts oder kompromittierte Dependencies können dieselben Designfehler ausnutzen, nur mit anderem Startpunkt.

Incident Response: Was nachträglich prüfen?

Wenn vor dem Patch Gemini-Workflows mit öffentlichen Issues, Pull Requests oder Kommentaren liefen, lohnt sich ein rückblickender Blick in die GitHub-Actions-Historie. Suchen Sie nach ungewöhnlichen Workflow-Dispatches, verdächtigen Ausgaben, unerwarteten Token- oder OIDC-Nutzungen, Repository-Schreibzugriffen und Runs, die länger offen gehalten wurden als normal. Bei Verdacht sollten erreichbare Secrets rotiert werden.

Wichtig ist, nicht nur den Gemini-Workflow isoliert zu betrachten. Pillars Analyse zeigt gerade den Pivot über andere Workflows. Prüfen Sie also auch Jobs, die vom betroffenen Token aus gestartet werden konnten und höhere Rechte hatten. In GitHub Actions ist der zweite Workflow oft der eigentliche Schadenverstärker.

Kurzantwort für Entscheider

Die Gemini-CLI-Schwachstelle GHSA-wpqr-6v78-jr5g ist ein CVSS-10-Risiko für Unternehmen, die AI-Agenten in CI/CD einsetzen. Die technische Ursache liegt in Workspace Trust, Tool-Allowlisting und überprivilegierten GitHub-Actions-Workflows. Gepatchte Versionen sind verfügbar; das größere Thema bleibt aber die Governance von AI-Agenten, die untrusted Input lesen und gleichzeitig Tools, Secrets oder Schreibrechte besitzen.

Für Security-Teams ist das ein guter Anlass, AI-Coding-Agenten nicht mehr als „nur Chatbot im Build-Log” zu behandeln. Sobald ein Agent Shell-, Repository-, Cloud- oder GitHub-CLI-Zugriff hat, gehört er in Threat Models, Least-Privilege-Prüfungen, Secret-Reviews und Incident-Response-Playbooks.