KI-Sandbox-Ausbrüche treffen Codex, Cursor und Gemini CLI

Sicherheitsforscher haben KI-Sandbox-Ausbrüche identifiziert, die vier weit verbreitete Coding-Agenten betreffen: Codex CLI, Cursor, Gemini CLI und Google Antigravity.

Die Schwachstellen erfordern nicht zwangsläufig, dass ein Angreifer direkt aus der Sandbox ausbricht. Stattdessen kann ein KI-Agent innerhalb der Sandbox eine Datei im Projektarbeitsbereich erstellen, die später von einem vertrauenswürdigen Werkzeug auf dem Hostsystem gelesen oder ausgeführt wird. Diese Interaktion kann anschließend zur Ausführung von Code außerhalb der Sandbox führen.

Die Forscher Eilon Cohen, Dan Lisichkin und Ariel Fogel von Pillar Security veröffentlichten ihre Ergebnisse im Rahmen der Serie Week of Sandbox Escapes. Die meisten der gemeldeten Probleme wurden inzwischen von den betroffenen Anbietern behoben oder bestätigt.

So funktionieren KI-Sandbox-Ausbrüche

KI-Coding-Agenten dürfen in der Regel Dateien innerhalb eines Projektarbeitsbereichs erstellen und bearbeiten. Gleichzeitig laufen das Betriebssystem, der Code-Editor und die Entwicklungswerkzeuge außerhalb der Sandbox des Agenten.

Dadurch entsteht ein Sicherheitsrisiko, wenn vertrauenswürdige Werkzeuge auf dem Hostsystem automatisch Dateien verarbeiten, die der Agent verändern kann.

Ein Entwicklungswerkzeug kann beispielsweise einen Python-Interpreter überprüfen, eine Workspace-Aufgabe ausführen, eine Hook-Konfiguration laden, Git-Metadaten analysieren oder mit einem lokalen Docker-Dienst kommunizieren. Gelingt es einem Angreifer, den KI-Agenten dazu zu bringen, eine entsprechende Datei zu erstellen oder zu verändern, kann das vertrauenswürdige Werkzeug später vom Angreifer kontrollierten Code ausführen.

Der erste Auslöser kann eine indirekte Prompt-Injection sein. Eine schädliche Anweisung kann in einer README-Datei, einer Software-Abhängigkeit, einem Pull Request, einem Issue oder einem Code-Diff verborgen sein. Der KI-Agent kann dieser Anweisung anschließend folgen und eine schädliche lokale Änderung vornehmen.

Pillar Security ordnete die Ergebnisse vier Hauptkategorien zu:

• Denylist-basierte Sandboxes, die das Verhalten des Betriebssystems nicht ausreichend berücksichtigen.
• Workspace-Konfigurationsdateien, die als ausführbarer Code fungieren können.
• Befehls-Whitelists, die lediglich den Befehlsnamen prüfen, unsichere Argumente jedoch ignorieren.
• Privilegierte lokale Dienste, auf die KI-Agenten außerhalb der Sandbox zugreifen können.

Cursor-Schwachstellen ermöglichten Codeausführung auf dem Hostsystem

Die Forscher entdeckten drei separate Schwachstellen in Cursor.

Die erste betraf eine .claude-Hook-Konfiguration, die über den Arbeitsbereich gesteuert wird. Ein Angreifer konnte sie missbrauchen, um Befehle außerhalb der Sandbox auszuführen. Die Schwachstelle trägt die Kennung CVE-2026-48124 und wurde in Cursor Version 3.0.0 behoben.

Die zweite Schwachstelle ermöglichte es einem KI-Agenten, einen Python-Interpreter in einer virtuellen Umgebung zu verändern. Die Python-Erweiterung von Cursor konnte diesen Interpreter anschließend automatisch bei der Überprüfung der Entwicklungsumgebung ausführen.

Die dritte Schwachstelle nutzte Git-Metadaten aus, die außerhalb des üblichen .git-Verzeichnisses gespeichert waren. Dadurch ließ sich die fsmonitor-Funktion von Git missbrauchen und gleichzeitig der pfadbasierte Schutz von Cursor umgehen. Das Problem wurde in Version 3.0.0 behoben. Eine CVE-Nummer steht jedoch noch aus.

Codex CLI und gemeinsam genutzter Docker-Socket

In Codex CLI stellten die Forscher fest, dass eine Befehls-Whitelist git show allein anhand des Befehlsnamens als sicher einstufte. Tatsächlich ließ sich der Befehl jedoch mit Argumenten ausführen, die keineswegs schreibgeschützt waren.

OpenAI behob das Problem in Codex CLI Version 0.95.0 und vergab dafür eine Bug-Bounty-Prämie mit hoher Einstufung. Eine CVE-Nummer wurde bislang nicht vergeben.

Ein weiteres Problem betraf Codex, Cursor und Gemini CLI. Die Agenten konnten auf einen Docker-Socket zugreifen, der von einem privilegierten lokalen Dienst bereitgestellt wurde. Dadurch entstand ein Weg zur Codeausführung außerhalb der Sandbox. Die betroffenen Anbieter haben dieses Problem inzwischen behoben.

Google stufte Antigravity-Berichte herab

Pillar Security meldete außerdem zwei Schwachstellen in Google Antigravity.

Die erste betraf eine Umgehung der macOS-Seatbelt-Denylist. Die zweite nutzte eine .vscode-Task-Konfiguration, um die Schutzmechanismen des Secure Mode zu umgehen.

Google bestätigte beide Meldungen als gültige Schwachstellen, stufte ihre Schwere jedoch herab. Das Unternehmen begründete dies damit, dass die Angriffe auf Social Engineering oder darauf angewiesen seien, dass ein Entwickler ein Repository mit indirekter Prompt-Injection öffnet.

Die Forscher argumentieren jedoch, dass genau diese Vertrauensgrenze das eigentliche Risiko darstellt. Entwickler erkennen möglicherweise nicht, dass ein KI-Agent Dateien verändern kann, die später von vertrauenswürdigen lokalen Werkzeugen ausgeführt werden.

KI-Sandbox-Ausbrüche bleiben ein grundlegendes Sicherheitsproblem

Das zugrunde liegende Problem ist nicht neu. Frühere Untersuchungen beschrieben bereits konfigurationsbasierte Sandbox-Ausbrüche in mehreren KI-Coding-Werkzeugen, bei denen innerhalb der Sandbox erstellte Dateien später auf dem Hostsystem ausgeführt werden konnten.

Die aktuellen Ergebnisse zeigen, dass das Problem mehrere Produkte und Anbieter betrifft. Für Entwickler lautet die entscheidende Frage daher nicht nur, ob ein KI-Coding-Agent über eine Sandbox verfügt.

Entscheidend ist vielmehr, ob lokale Werkzeuge die vom Agenten erstellten Dateien sicher verarbeiten können.