7 Min. Lesezeit

Pillar Security hat am 16. April 2026 eine Schwachstelle im Google-Gemini-CLI gemeldet, Google hat sie am 24. April unter GHSA-wpqr-6v78-jr5g geschlossen. CVSS-Score: 10.0. Ein externer Pull-Request-Beitragender konnte vor dem Initialisieren der Sandbox Code auf einem CI-Runner ausführen. Wer Gemini-CLI heute noch in Version 0.38 oder älter im Pipeline-Stack hat, hat ein Multi-Tenant-Problem, das nicht in der eigenen Cloud-Konsole sichtbar wird.

Verwandt:Platform Engineering Compliance NIS2/DORA  /  Google Gemini im Unternehmen

Was Pillar Security konkret demonstriert hat

Was ist die Gemini-CLI-Schwachstelle GHSA-wpqr-6v78-jr5g? Es handelt sich um eine Remote-Code-Execution-Lücke im Google-Gemini-CLI und der zugehörigen GitHub-Action, die ein externer Pull-Request-Beitragender ausnutzen konnte, um auf dem CI-Runner Befehle auszuführen, bevor die Tool-Sandbox initialisiert wurde. Google hat die Lücke mit CVSS 10.0 bewertet, was die maximale Severity auf der CVSS-3.1-Skala ist. Patch-Versionen sind Gemini-CLI 0.39.1 und google-github-actions/run-gemini-cli 0.1.22.

Die Mechanik ist deutlich konkreter als die übliche CVE-Beschreibung. Pillar Security demonstrierte den Angriff zunächst am Google-eigenen Repository draco, dann am 20. April direkt am Gemini-CLI. Der Trigger war ein Pull-Request mit präparierten Workspace-Inhalten. Im Headless-Mode der CLI wurde der Workspace-Ordner ohne weitere Bestätigung als vertrauenswürdig behandelt, eine lokale .gemini-Konfigurationsdatei aus dem PR konnte geladen werden und der –yolo-Modus ignorierte feingranulare Tool-Allowlists.

Das Resultat war ein Prompt-Injection-Pfad, der zu beliebigen Shell-Befehlen führte. Der Runner sah die Sequenz als legitime KI-Anweisung, der Sandbox-Start kam zu spät, die Credentials waren bereits aufgesammelt. Wer das in einem Open-Source-Repo betreibt, bei dem PRs von externen Beitragenden routinemäßig getestet werden, hatte einen offenen Bypass für Wochen, ohne dass etwas im Audit-Log nach Angriff aussah.

Warum das in der Multi-Tenant-Brille besonders weh tut

Cloud-Architekten kennen den CVSS-10-Reflex: alle Hände auf den Tisch, Patch-Plan, Audit. Was Gemini-CLI besonders unangenehm macht, ist die strukturelle Eigenschaft, dass es im CI/CD-Kontext mit den hochprivilegierten Rechten der Pipeline läuft. Eine kompromittierte Pipeline kann signierte Container-Images bauen, Cloud-Credentials erneuern, Helm-Charts ausrollen, Terraform-States manipulieren.

Wer in einer Multi-Tenant-Plattform arbeitet, sieht das schmerzhafter. Ein Pipeline-Job, der für mehrere Kunden produziert, bringt im Fall einer RCE potenziell Daten oder Build-Artefakte aus fremden Mandaten in Bewegung. Ein Pipeline-Job, der nur den eigenen Mandanten bedient, aber auf einer geteilten Cloud-Run-Instanz läuft, gibt dem Angreifer ein potenzielles Lateral-Movement-Ziel.

Das ist nicht der erste Hyperscaler-CVSS-10-Vorfall in diesem Jahr. CVE-2026-32202 zwang die CISA im April in die KEV-Liste, mit Frist und Druck auf Federal-Agencies. Die Lehre ist dieselbe: AI-CLIs sind Software wie jede andere Build-Software auch und sie gehören in den gleichen Patch-, Audit- und Allowlist-Prozess.

CI/CD-Mitigationen für Cloud-Teams: was trägt, was bricht

Die linke Spalte ist nicht theoretisch. Wer in den letzten drei Monaten Gemini-CLI in einer Action eingebunden hat, sollte heute die Run-Logs der CI nach präparierten Workspace-Konfigs durchsuchen, die unmittelbar vor der ersten Tool-Aktion gelesen wurden. Pillar Security stellt eine Indicator-of-Compromise-Liste im veröffentlichten Bericht zur Verfügung. Diese Liste gehört in das eigene SIEM, bevor die nächste Audit-Runde beginnt.

Workload-Identity-Federation ist der unterschätzte zweite Hebel. Ein Pipeline-Run, der seine GCP-Credentials nicht aus einem statischen Service-Account-Key zieht, sondern OIDC-basiert pro Lauf neu föderiert, hat im RCE-Fall keinen langlebigen Token zum Verbrennen.

Patch-Fahrplan: vom Audit bis zur sauberen Pipeline

Zwei Wochen sind realistisch, wenn das Platform-Team in das Hard-Pin der Action-Version einsteigt und nicht parallel die nächste Plattform-Migration plant. Wer mehrere Tenants betreibt, wird in Woche drei und vier zusätzlich die Tool-Allowlists pro Mandant einziehen, was nochmal Aufwand bedeutet, aber operativ keine neue Architektur ist.

Was bleibt offen

Pillar Security hat den Bug für eine Bounty gemeldet, aber die Höhe nicht offengelegt. Das ist im Google-VRP-Kontext üblich und gibt keinen Hinweis auf die Schwere. Wichtiger ist das Muster: AI-CLIs werden zur ersten Linie der CI-Sicherheit, weil sie die direkte Verbindung von externem Prompt-Input zu Shell-Execution darstellen. Die nächste vergleichbare Welle wird wahrscheinlich nicht in einem CLI liegen, sondern in einer eingebetteten Agent-API oder in einer LLM-betriebenen Build-Logik.

Wer also Gemini-CLI heute patcht, schließt einen Vorfall. Wer die Pipeline gleichzeitig auf Workload-Identity, Tool-Allowlists und Pre-Sandbox-Audit-Logging umstellt, schließt eine Klasse.

Häufige Fragen

Bin ich betroffen, wenn ich Gemini-CLI nur lokal nutze?

Das Risiko in Headless-CI-Pipelines ist deutlich höher als im interaktiven lokalen Einsatz, weil dort der Trust-Schritt fehlt. Lokal ist der –yolo-Flag das eigentliche Problem. Wer ihn auch lokal nicht aktiviert hat und mit einer Version unter 0.39.1 arbeitet, sollte trotzdem zügig aktualisieren.

Reicht ein Versions-Pin in der GitHub-Action aus?

Nicht allein. Ein Versions-Pin auf 0.1.22 beziehungsweise SHA ist die Grundlinie. Daneben braucht es Tool-Allowlists pro Job und idealerweise ein separates Runner-Profil für Pull-Request-Validations, das keine Cloud-Credentials hält. Defense in Depth ist hier kein Lehrbuch-Slogan, sondern operativ relevant.

Wie erkenne ich, ob die Lücke in den letzten Wochen ausgenutzt wurde?

Pillar Security hat im Disclosure-Bericht Indikatoren veröffentlicht. Praktisch sucht man in den Action-Logs nach präparierten .gemini-Konfigurationen, die direkt vor der ersten Tool-Operation eingelesen wurden und nach Shell-Sub-Aufrufen, die außerhalb des erwarteten Allowlist-Bestands liegen. Ein SIEM-Lookback über die letzten 30 Tage ist eine angemessene Mindest-Sicht.

Was bedeutet das für Multi-Tenant-Plattform-Teams?

Für jeden Mandanten gilt das gleiche Patch-Datum. Wer das per Plattform-Update einmal zentral durchziehen kann, ist im Vorteil. Wer Tenant-spezifische Pipelines erlaubt, muss jeden Tenant einzeln auf die Patched-Version anheben und das gegenüber Audit dokumentieren.

Gibt es einen direkten Bezug zu CISA-KEV?

Aktuell ist diese Gemini-CLI-Lücke nicht in der KEV gelistet, weil Pillar Security im verantwortungsvollen Disclosure-Prozess gemeldet hat und der Patch vor Ausnutzung verfügbar war. Das schließt eine Aufnahme aber für die Zukunft nicht aus, falls Ausnutzung in freier Wildbahn dokumentiert wird.

Bildquelle: KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt