Sicherheitslücke in Cursor-IDE: Agent-Befehle als Angriffsvektor aufgedeckt

Sicherheitsforscher von Pillar Security haben eine erhebliche Schwachstelle in der KI-gestützten Entwicklungsumgebung Cursor aufgedeckt. Die als CVE-2026-22708 klassifizierte Lücke ermöglicht Angreifern die Ausführung von Remote-Code durch Manipulation von Umgebungsvariablen – selbst bei leerer Befehlsliste. Die Attacke nutzt vermeintlich harmlose Shell-Befehle wie export oder typeset, um Sicherheitsmechanismen zu umgehen.

Neue Angriffsdimension in agentenbasierten Entwicklungsumgebungen

Die Schwachstelle offenbart eine grundsätzliche Problematik in der Architektur KI-gestützter Entwicklungswerkzeuge. Durch Manipulation implizit vertrauenswürdiger Shell-Befehle können Angreifer unbemerkt Umgebungsvariablen verändern, die das Verhalten etablierter Entwicklertools wie Git oder Python beeinflussen.

Die Forscher dokumentierten zwei Angriffskategorien:

One-Click-Angriffe: Der Nutzer genehmigt einen scheinbar unbedenklichen Befehl, der aufgrund der kompromittierten Umgebung schadhaften Code aktiviert.

Zero-Click-Angriffe: Durch Ausnutzung von Shell-Syntax-Eigenheiten können Angreifer ohne jede Nutzerinteraktion schadhaften Code in Konfigurationsdateien schreiben oder unmittelbare Codeausführung erreichen.

Statische Kontrollen wie Allowlists verschärfen die Problematik zusätzlich, da sie genau jene Befehle automatisch genehmigen, die zur Auslösung der Schadroutine benötigt werden. Das jahrzehntelang gültige Vertrauensmodell greift in agentenbasierten Umgebungen nicht mehr.

Grafik Quelle: Pillar Security

Paradigmenwechsel im Bedrohungsmodell

Traditionelle Sicherheitsmodelle basieren auf der Annahme menschlicher Beteiligung. Agentenbasierte IDEs durchbrechen diese Grundannahme: Sie führen Befehle programmgesteuert aus, ohne zwischen Anweisungen und Daten unterscheiden zu können, und befolgen Instruktionen aus externen Quellen mit vollen Nutzerberechtigungen.

Die derzeitigen Industriestandards erweisen sich als unzureichend, da sie auf Inhaltsbereinigung statt Ausführungsisolierung setzen. Der richtige Ansatz besteht im Übergang zu Isolierungslösungen, die Codeausführung abgrenzen.

Cursors Sicherheitsarchitektur und ihre Schwachstellen

Cursor implementiert zwei Schutzmechanismen: eine nutzerkontrollierte Zulassungsliste und einen serverseitigen Mechanismus zur Befehlsevaluierung. In der Praxis ließ sich die zweite Kontrolle durch Shell-Built-ins umgehen, die implizit als vertrauenswürdig gelten und ohne Nutzerbestätigung ausgeführt werden.

Die zentrale Schwachstelle: Shell-Built-in-Befehle werden ohne Nutzereinwilligung ausgeführt, selbst bei leerer Befehlsliste. Der interne Auswertungsmechanismus umgeht diese Befehle und markiert sie als sicher.

Dokumentierte Angriffsvektoren

Die Forscher identifizierten mehrere Umgebungsvariablenketten für Ein-Klick- und Null-Klick-RCEs. Die initiale Schutzmaßnahme des Cursor-Teams adressiert bestimmte Auslösepfade, während die zugrundeliegende Schwachstellenklasse weiterhin ausnutzbar bleibt.

Zero-Click-Angriffe

Beliebiges Dateischreiben via Export: Der export-Befehl ermöglicht beliebiges Dateischreiben mit angreifergesteuerten Inhalten ohne Nutzerinteraktion. Cursor erkennt nicht, dass eine Here-String-Kombination mit Ausgabeleitung beliebiges Dateischreiben ermöglicht. Angreifergesteuerte Inhalte werden an ~/.zshrc angehängt und bei jeder neuen Shell-Sitzung ausgeführt.

Direkte RCE über typeset/declare: Der typeset-Befehl ermöglicht direkte Befehlsausführung durch Missbrauch der zsh-Parametererweiterungsflags. Das Erweiterungsflag (e) erzwingt die Auswertung nach dem Parsen, wodurch die Zeichenfolge als Code ausgeführt wird – ohne Bestätigungsaufforderung.

Ein-Klick-Angriffe

PAGER-Hijacking: Tools wie git und man nutzen die Umgebungsvariable PAGER zur Bestimmung der Ausgabeanzeige. Nach Manipulation dieser Variable löst die Ausführung von git branch angreifergesteuerten Code aus. Viele Nutzer führen solche Befehle auf ihrer Whitelist, wodurch die menschliche Kontrolle umgangen wird.

Python-Warnungshandler-Kette: Diese Methode verkettet mehrere Umgebungsvariablen (PYTHONWARNINGS, BROWSER, PERL5OPT), um über das Python-Modul antigravity und das Perl-Skript perlthanks beliebigen Code auszuführen. Während früher physischer Zugriff nötig war, führt Cursor den Code mit erhöhten Berechtigungen aus.

Wirksamkeit der Angriffsmethode

Strukturelle Schwäche von Allowlists: Allowlists und Bereiniger sind für KI-Coding-Agenten ungeeignet, da diese Code als Eingabe erwarten. Die erweiterte Angriffsfläche lässt zu viele Befehlsinjektionsprimitive zu. Der richtige Ansatz: vollständige Befehlsausführung in isolierten Umgebungen.

Unsichtbare Vorbereitung: Der Angriff trennt schadhafte Einrichtung von der auslösenden Aktion. Nutzer sehen nur harmlose Befehle wie git branch, während die Vergiftungsphase stillschweigend über vertrauenswürdige Built-ins erfolgt.

Ausnutzung etablierter Vertrauensverhältnisse: Entwickler setzen häufig genutzte Befehle routinemäßig auf die Zulassungsliste. Diese werden zu Angriffsvektoren, da der Angreifer nur die Umgebung vergiften und warten muss.

export_calc_pop #2

Transformation des Bedrohungsmodells durch KI-Agenten

Die Technik basiert auf Forschungsergebnissen von 2020, die zeigten, wie durch Manipulation von Umgebungsvariablen RCE erreicht werden kann. Damals stellte der Angriff nur begrenzte Bedrohung dar, da er direkten Zugriff auf den Rechner, manuelle Ausführung und bereits installierte Interpreter erforderte.

KI-Agenten beseitigen diese Hindernisse: Sie lassen sich durch Prompt-Injection manipulieren, führen Befehle programmgesteuert aus und verketten Operationen ohne menschliches Eingreifen. Was einst physischen Zugriff erforderte, lässt sich nun aus der Ferne durch schadhafte Inhalte ausnutzen.

Implementierte Lösung

Cursor hat das Problem behoben, indem es für alle Befehle, die der serverseitige Parser nicht klassifizieren kann, ausdrückliche Nutzerzustimmung verlangt. Allerdings bleiben Nutzer bei Verwendung vorhersehbarer Zulassungslisten gefährdet. Um dies zu mindern, hat Cursor neue Sicherheitsrichtlinien eingeführt, die von Zulassungslisten abraten.

Timeline der verantwortungsvollen Offenlegung

11. August 2025 – Schwachstelle an Cursor gemeldet
August 2025 – Cursor bestätigt das Problem
September 2025 – Cursor bestätigt „systemisches Problem“, für das „zwei wichtige Initiativen in Arbeit“ sind
Januar 2026 – Cursor veröffentlicht Fix und schließt das Problem

Strategien zur Risikominderung

Sicherheitsverantwortliche sollten Shell-Built-Ins als sicherheitsrelevante Vorgänge behandeln und Sandbox-Einrichtung für Befehlsausführung sowie Änderungen an Umgebungsvariablen implementieren. Die Isolierung von Umgebungsvariablen zwischen Agent-Sitzungen sollte erwogen werden.

Cursor warnt: „Wir haben eine Zulassungsliste, aber sie ist keine Sicherheitsgarantie. Umgehungen sind möglich. Verwenden Sie niemals den Modus ‚Run Everything‘.“

Fazit

Die offengelegte Technik zeigt: Funktionen für menschenkontrollierte Umgebungen werden zu Angriffsvektoren, wenn autonome Agenten manipuliert werden können. Die Schwachstelle erforderte keine Zero-Days oder komplexe Ausnutzungstechniken – nur die Erkenntnis, dass KI-Agenten unter anderen Vertrauensannahmen operieren.

Mit zunehmender Einbettung von KI-Assistenten in Entwicklungsworkflows muss die Sicherheitsgemeinschaft jede „sichere“ Funktion auf ihr Verhalten unter autonomer Ausführung überprüfen – bevor Angreifer dies tun.

„Die in diesem Beitrag bereitgestellten Informationen wurden sorgfältig recherchiert, erheben jedoch keinen Anspruch auf Vollständigkeit oder absolute Richtigkeit. Sie dienen ausschließlich der allgemeinen Orientierung und ersetzen keine professionelle Beratung. Die Redaktion übernimmt keine Haftung für eventuelle Fehler, Auslassungen oder Folgen, die aus der Nutzung der Informationen entstehen.“

Entdecke mehr