Der Kern des Problems bei Gemini CLI lag in der automatischen Vertrauensstellung gegenüber dem aktuellen Arbeitsverzeichnis. Google erklärte in seinem kürzlich veröffentlichten Hinweis, dass frühere Versionen in CI-Umgebungen – also im Headless-Modus – Arbeitsverzeichnisse automatisch vertrauten, um Konfiguration und Umgebungsvariablen zu laden. Lief das Werkzeug dabei auf nicht vertrauenswürdigen Verzeichnissen, etwa bei der Prüfung von eingereichten Pull Requests, konnten schädliche Umgebungsvariablen im lokalen Verzeichnis „.gemini/" zu Remote Code Execution führen.
Weil das Werkzeug jede gefundene Agenten-Konfiguration ohne Prüfung, Sandbox oder ausdrückliche Zustimmung lud, hätte ein Angreifer eine präparierte Konfiguration platzieren und so Code auf dem Host ausführen können. Damit ließen sich CI/CD-Pipelines effektiv in Pfade für Lieferketten-Angriffe verwandeln.
Das Update verlangt nun, dass Verzeichnisse ausdrücklich als vertrauenswürdig markiert werden, bevor auf Konfigurationsdateien zugegriffen werden kann. Google weist darauf hin, dass jede Nutzung im Headless-Modus ohne diese Vertrauensstellung eine manuelle Prüfung erfordert. Nutzer werden aufgefordert, ihre Workflows zu überprüfen.
Zusätzlich härtet Google die Freigabeliste für Werkzeuge ab, wenn Gemini CLI im sogenannten „–yolo"-Modus läuft. Bisher ignorierte dieser Modus die Freigabeliste in „~/.gemini/settings.json" und führte alle Werkzeugaufrufe – einschließlich „run_shell_command" – automatisch ohne Bestätigung aus, was über Prompt Injection zu Codeausführung führen konnte. Laut Google wertet die Richtlinien-Engine in Version 0.39.1 die Freigabeliste nun auch im „–yolo"-Modus aus; einige bislang darauf angewiesene Workflows könnten dadurch ohne Anpassung der Freigabelisten stillschweigend fehlschlagen.
Novee Security verwies zugleich auf eine hochgradige Schwachstelle im Entwicklungswerkzeug Cursor vor Version 2.5 (CVE-2026-26268, CVSS 8.1), die ebenfalls über Prompt Injection zu beliebiger Codeausführung führen kann. Cursor beschrieb den Fall in einer Meldung vom Februar 2026 als Sandbox-Ausbruch über „.git"-Konfigurationen: Ein bösartiger Agent kann ein leeres Repository („.git") mit einem schädlichen Git-Hook anlegen, der bei jedem Commit-Vorgang ohne Nutzerinteraktion automatisch ausgelöst wird.
Sicherheitsforscher Assaf Levkovich betonte, die Ursache liege nicht in der Kernlogik von Cursor, sondern in einem Zusammenspiel von Funktionen in Git, das ausnutzbar werde, sobald ein KI-Agent eigenständig Git-Operationen in einem Repository ausführe, das er nicht kontrolliere. Ein schädlicher Pre-Commit-Hook in einem verschachtelten leeren Repository werde unsichtbar ausgeführt – außerhalb der Argumentationskette des Agenten und außerhalb des Sichtfelds des Nutzers.
Zeitgleich wurde eine weitere hochgradige Schwachstelle bei der Zugriffskontrolle in der Entwicklungsumgebung entdeckt (CVSS 8.2): Jede installierte Erweiterung kann auf sensible API-Schlüssel und Zugangsdaten zugreifen, die lokal in einer SQLite-Datenbank gespeichert sind. Das von LayerX „CursorJacking" genannte Problem ermöglicht laut Forscher Roy Paz die Offenlegung von Sitzungstokens und API-Schlüsseln, unbefugten Zugriff auf Cursor-Backend-Dienste sowie Datendiebstahl durch Identitätsmissbrauch – und ist bislang nicht behoben.
Cursor hält dem entgegen, der Zugriff sei auf den lokalen Rechner beschränkt, auf dem der Nutzer die Erweiterung bereits installiert und ihr Berechtigungen erteilt habe. Nutzer sollten daher ausschließlich vertrauenswürdige Erweiterungen herunterladen.