**Google** hat eine Sicherheitslücke mit maximaler Schwere in **Gemini CLI** – dem `@google/gemini-cli` npm-Paket und dem `google-github-actions/run-gemini-cli` **GitHub Actions** Workflow – geschlossen, die Angreifern die Ausführung beliebiger Befehle auf Host-Systemen ermöglicht hätte. **Gemini CLI Remote Code Execution** "Die Schwachstelle erlaubte einem externen Angreifer ohne Privilegien, eigene bösartige Inhalte als **Gemini**-Konfiguration zu laden", sagte **Novee Security** in einem Bericht vom Mittwoch. "Dies löste die Befehlsausführung direkt auf dem Host-System aus und umging die Sicherheit, bevor die Sandbox des Agenten überhaupt initialisiert wurde." Die Schwäche, für die keine **CVE**-Kennung existiert, hat einen **CVSS**-Score von 10,0. Sie betrifft die folgenden Versionen: * `@google/gemini-cli < 0.39.1` * `@google/gemini-cli < 0.40.0-preview.3` * `google-github-actions/run-gemini-cli < 0.1.22` In seiner Veröffentlichung letzte Woche gab **Google** an, dass die Auswirkungen auf Workflows beschränkt sind, die **Gemini CLI** im Headless-Modus verwenden, und fügte hinzu, dass jede Nutzung des Tools im Headless-Modus ohne Ordnervertrauen eine manuelle Überprüfung zur Konfiguration dieses Vertrauensmechanismus erfordert. "In früheren Versionen vertraute **Gemini CLI**, das in CI-Umgebungen (Headless-Modus) lief, automatisch Arbeitsordnern zum Laden von Konfigurationen und Umgebungsvariablen", hieß es. Dieses automatische Vertrauen in den aktuellen Arbeitsordner bedeutete, dass das Tool jede gefundene Agentenkonfiguration ohne Überprüfung, Sandboxing oder explizite Benutzerzustimmung laden konnte. Ein Angreifer konnte dieses Verhalten ausnutzen, indem er eine speziell präparierte Konfiguration einfügte, die zur Codeausführung auf dem Host, der den Agenten ausführt, führen konnte, wodurch CI/CD-Pipelines effektiv zu Angriffspfaden in der Lieferkette wurden. Das Update behebt das Problem, indem Ordner explizit vertrauenswürdig sein müssen, bevor Konfigurationsdateien abgerufen werden können. Daher werden Benutzer aufgefordert, ihre Workflows zu überprüfen und einen der beiden Ansätze zu wählen: * Wenn der Workflow mit vertrauenswürdigen Eingaben ausgeführt wird (z. B. Überprüfung von Pull-Anfragen von vertrauenswürdigen Mitarbeitern), setzen Sie `GEMINI_TRUST_WORKSPACE: 'true'` im Workflow. * Wenn der Workflow mit nicht vertrauenswürdigen Eingaben ausgeführt wird, überprüfen Sie die Anleitungen von **Google** in `google-github-actions/run-gemini-cli`, um den Workflow gegen bösartige Inhalte abzusichern, und setzen Sie die Umgebungsvariable. Der Tech-Gigant merkte auch an, dass er Schritte unternimmt, um die Tool-Allowlist zu härten, wenn **Gemini CLI** im `--yolo`-Modus konfiguriert ist, um Szenarien zu verhindern, in denen nicht vertrauenswürdige Eingaben (z. B. von Benutzern eingereichte **GitHub**-Probleme) zur Remote-Codeausführung durch Prompt-Injection führen könnten, indem die Tatsache ausgenutzt wird, dass der Auto-Approve-Modus jede Allowlist in `~/.gemini/settings.json` ignorieren und alle Tool-Aufrufe automatisch ausführen würde (einschließlich "run_shell_command") ohne Benutzerbestätigung. "In Version 0.39.1 evaluiert die **Gemini CLI**-Richtlinien-Engine nun die Tool-Allowlist im `--yolo`-Modus, was für CI-Workflows nützlich ist, die einige sichere Befehle zulassen, wenn nicht vertrauenswürdige Eingaben verarbeitet werden", sagte **Google**. "Infolgedessen können einige Workflows, die zuvor von diesem Verhalten abhingen, stillschweigend fehlschlagen, es sei denn, die Tool-Allowlists werden an die Aufgabe angepasst." ### **Cursor** Bug führt zu Codeausführung  Die Enthüllung erfolgt, während **Novee Security** auch eine Schwachstelle mit hoher Schwere in dem KI-gestützten Entwicklungstool **Cursor** vor Version 2.5 (**CVE-2026-26268**, **CVSS**-Score: 8,1) hervorgehoben hat, die ebenfalls zur Ausführung beliebiger Code durch Prompt-Injection führen könnte. **Cursor** beschrieb dies in einer Warnung vom Februar 2026 als einen Fall von Sandbox-Escape durch `.git`-Konfigurationen, der es einem bösartigen Agenten ermöglicht, ein Bare-Repository (`.git`) mit einem bösartigen [**Git** Hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) einzurichten, der jedes Mal automatisch ausgelöst wird, wenn eine Commit-Operation im eingebetteten Repository-Kontext ausgeführt wird, ohne dass eine Benutzerinteraktion erforderlich ist. Das Endergebnis ist eine automatisch genehmigte Ausführung von beliebigem Code auf der Maschine des Opfers durch die folgende Aktionssequenz: * Benutzer klont ein öffentliches **GitHub**-Repository mit dem eingebetteten Bare-Repository, das einen bösartigen Post-Checkout-Hook enthält * Benutzer öffnet das Repository in **CursorIDE** * Benutzer stellt eine harmlose Aufforderung, "den Code zu erklären" * Der **Cursor**-Agent parst die AGENTS.md, die ihn anweist, zum Bare-Repository zu navigieren und einen "git checkout" des Master-Branches durchzuführen * Der Post-Checkout-Hook innerhalb des Bare-Repositorys wird ausgelöst, was zur Codeausführung führt. "Die Grundursache ist kein Fehler in der Kernlogik von **Cursor**, sondern vielmehr eine Folge einer Feature-Interaktion in **Git**, die ausnutzbar wird, sobald ein KI-Agent autonom **Git**-Operationen innerhalb eines Repositorys ausführt, das er nicht kontrolliert", sagte der Sicherheitsforscher Assaf Levkovich. "Wenn der Agent `git checkout` als Teil der Erfüllung einer Routineanfrage ausführt, tut er nichts, was der Benutzer nicht implizit autorisiert hat. Aber weder der Benutzer noch der Agent haben Einblick in das, was die **Cursor** Rules des Repositorys in Gang gesetzt haben. Ein bösartiger Pre-Commit-Hook, der in einem verschachtelten Bare-Repository eingebettet ist, wird stillschweigend ausgeführt, außerhalb der Denkweise des Agenten und außerhalb des Blickfelds des Benutzers." ### **CursorJacking**: Diebstahl von API-Schlüsseln Die Ergebnisse fallen auch mit der Entdeckung einer weiteren Schwachstelle mit hoher Schwere bei der Zugriffskontrolle in der IDE zusammen (**CVSS**-Score: 8,2), die es jeder installierten Erweiterung ermöglichen könnte, auf sensible API-Schlüssel und Anmeldeinformationen zuzugreifen, die lokal in einer **SQLite**-Datenbank gespeichert sind, was zu Kontoübernahmen, Datenlecks und finanziellen Verlusten durch unbefugte API-Nutzung führen kann. Das Problem, von **LayerX** als **CursorJacking** bezeichnet, ist noch nicht behoben. "**Cursor** erzwingt keine Zugriffskontrollgrenzen zwischen Erweiterungen und dieser Datenbank", sagte **LayerX**-Forscher Roy Paz. "Die Ausnutzung dieser Schwachstelle kann zur Offenlegung von Sitzungstoken und API-Schlüsseln, unbefugtem Zugriff auf **Cursor**-Backend-Dienste und Datendiebstahl durch Benutzeridentitätswechsel führen." **Cursor** hat erklärt, dass der Zugriff auf die lokale Maschine beschränkt ist, auf der der Benutzer die Erweiterung bereits installiert und Berechtigungen erteilt hat. Das bedeutet, dass jede bösartige Erweiterung mit Zugriff auf das lokale Dateisystem potenziell wertvolle Informationen aus verschiedenen Datenspeichern der Anwendung extrahieren könnte. Um die Bedrohung einzudämmen, ist es unerlässlich, dass Benutzer nur vertrauenswürdige Erweiterungen herunterladen.