AI-gestuetzte Entwickler-Tools ruecken zunehmend in den Fokus von Angreifern. Aktuelle Schwachstellen in Google Gemini CLI und der AI-IDE Cursor zeigen, wie schnell Fehlkonfigurationen und unklare Vertrauensmodelle zu Remote Code Execution (RCE) und Supply-Chain-Angriffen fuehren koennen.
Google Gemini CLI: Kritische RCE-Sicherheitsluecke in CI/CD-Umgebungen
Google hat eine kritische Schwachstelle mit maximalem Schweregrad (CVSS-Basiswert 10.0) im Tooling rund um Gemini CLI behoben. Betroffen waren sowohl das npm-Paket @google/gemini-cli als auch das GitHub-Actions-Workflow-Template google-github-actions/run-gemini-cli. Die Luecke ermoeglichte Angreifern die Ausfuehrung beliebiger Befehle auf dem Hostsystem, noch bevor eine Sandbox aktiviert wurde.
Headless-Modus, vertrauenswuerdige Verzeichnisse und RCE-Angriffsszenario
Nach Analysen von Novee Security lag die Ursache in der Art und Weise, wie Gemini CLI im Headless-Modus – ein ueblicher Einsatzfall in CI/CD-Pipelines – mit der Arbeitsumgebung umging. Das Tool vertraute der aktuellen Arbeitsdirectory implizit und lud automatisch Konfigurationen und Umgebungsvariablen aus dem lokalen Verzeichnis .gemini/, ohne explizite Bestaetigung oder sand-boxing.
Ein Angreifer konnte somit ein Repository mit boeswilligen Agent-Konfigurationen vorbereiten und dieses beispielsweise ueber einen Pull Request in ein oeffentliches Projekt einspeisen. Sobald ein CI-Workflow, der Gemini CLI nutzt, dieses Repository verarbeitete, wurden die manipulierten Einstellungen geladen und fuehrten zu Remote Code Execution auf der CI-Maschine. Aehnliche Supply-Chain-Vorfaelle – etwa bei Build-Skripten oder CI-Tools wie beim historischen Codecov-Zwischenfall – zeigen, wie weitreichend die Folgen kompromittierter CI-Server sein koennen.
Besonders kritisch ist dieses Verhalten in Szenarien, in denen CI-Systeme nicht vertrauenswuerdige Inhalte bauen: Forks, externe Contributions oder automatisierte PR-Checks. Wird der Build-Server kompromittiert, koennen Angreifer manipulierte Artefakte ausliefern, geheime Zugangsdaten abgreifen oder weitere interne Systeme angreifen.
Sicherheitsupdates: Explizites Vertrauensmodell und geschaerfter –yolo-Modus
Mit der behobenen Version muessen Verzeichnisse explizit als vertrauenswuerdig markiert werden, bevor Gemini CLI Konfigurationen laedt. Teams sollten ihre GitHub Actions und CI/CD-Pipelines ueberpruefen und sicherstellen, dass nur bekannte, kontrollierte Verzeichnisse verwendet werden oder ein klares Trust-Modell implementiert ist.
Zusaetzlich hat Google den gefaehrlichen Parameter –yolo ueberarbeitet. Dieser Schalter schaltet automatische Bestaetigungen fuer Agent-Aktionen ein. Bisher wurden dabei Allowlist-Beschraenkungen in ~/.gemini/settings.json ignoriert, sodass auch hoechst riskante Werkzeuge wie run_shell_command ohne Rueckfrage ausgefuehrt werden konnten – ein Einfallstor fuer RCE durch Prompt Injection oder manipulierte GitHub-Issues.
Ab Gemini CLI Version 0.39.1 greift der Policy-Engine-Mechanismus nun auch im –yolo-Modus: Nur in der Allowlist definierte Kommandos duerfen automatisch ausgefuehrt werden. Organisationen muessen damit rechnen, dass bestehende Pipelines ohne Anpassung ihrer Allowlists stillscheigend fehlschlagen, gewinnen dafuer aber ein deutlich robusteres Sicherheitsniveau.
AI-IDE Cursor: Sandbox Escape und Credential-Diebstahl
CVE-2026-26268: Sandbox Escape via Git-Hooks
Parallel dazu meldete Novee Security eine hochkritische Schwachstelle in der AI-IDE Cursor bis Version 2.5 (CVE-2026-26268, CVSS 8.1). Die Luecke ermoeglicht Angreifern die Ausfuehrung von Code auf der Entwickler-Workstation durch eine Kombination aus Prompt Injection und Git-Funktionalitaet.
Cursor beschreibt das Problem als „Sandbox-Escape ueber .git-Konfiguration“. Ein Angreifer kann ein geschachteltes „bare“ Git-Repository mit boeswilligem Git-Hook (z.B. pre-commit) bereitstellen. Fuehrt der AI-Agent innerhalb von Cursor – im Namen des Nutzers – Aktionen wie git checkout oder Commits in diesem Repository aus, werden die Hooks automatisch und ausserhalb der Kontrolle des Agents mit den Rechten des Benutzers ausgefuehrt.
Die Ursache liegt weniger in einem einzelnen Programmierfehler, sondern in der gefaehrlichen Ueberschneidung von autonomen AI-Agenten und Git-Automatisierung. Sobald ein Agent ohne explizite Kontrolle Standard-Git-Operationen in fremden Repositories ausfuehrt, kann jeder ansonsten harmlose Befehl eine verdeckte RCE-Kette ausloesen.
CursorJacking: Erweiterungen mit Zugriff auf API-Schluessel und Tokens
Forschende von LayerX beschrieben zusaetzlich eine weitere hochriskante Schwachstelle in Cursor (CVSS 8.2), bekannt als CursorJacking. Ursache ist das Fehlen strikter Trennung zwischen installierten Erweiterungen und der lokalen SQLite-Datenbank mit sensitiven Informationen wie API-Schluesseln, Session-Tokens und weiteren Zugangsdaten.
Jedes installierte Cursor-Plugin, das lokalen Dateizugriff besitzt, kann diese Datenbank auslesen und somit:
- Benutzerkonten ueber Sitzungs-Tokens uebernehmen,
- Backend-Dienste von Cursor im Namen des Nutzers ansprechen,
- kostenpflichtige AI-APIs missbrauchen und Kosten verursachen,
- Projektdaten sowie AI-Chat-Historien exfiltrieren.
Zum Zeitpunkt der Veroeffentlichung gilt die Schwachstelle als nicht behoben. Die Entwickler von Cursor verweisen darauf, dass ein lokal installiertes und berechtigtes Plugin noetig sei. In der Praxis bedeutet dies jedoch, dass jedes boeswillige oder kompromittierte Plugin als Bruecke zum Diebstahl von Geheimnissen aus Cursor und anderen lokal gespeicherten Daten dienen kann – ein bekanntes Risiko aus dem Browser- und IDE-Plugin-Oekosystem.
Die beschriebenen Vorfaelle unterstreichen einen deutlichen Trend: AI-gestuetzte Entwicklungs- und CI/CD-Tools entwickeln sich zu priorisierten Angriffszielen. Organisationen sollten ihre Sicherheitsrichtlinien fuer AI-Agenten und Dev-Tools schaerfen: Werkzeuge strikt auf das notwendige Minimum beschraenken, Allowlists konsequent einsetzen, CI-Jobs auf gehärteten, moeglichst kurzlebigen Umgebungen ausfuehren, Geheimnisse aus lokalen Workstations und Repositories fernhalten und nur sorgfaeltig gepruefte Erweiterungen installieren. Wer AI-gestuetzte Tools produktiv nutzt, sollte diese Risiken regelmaessig neu bewerten und Sicherheitsupdates zeitnah ausrollen.
