Was Cato in Cursor fand

Cato AI Labs hat zwei kritische Schwachstellen in Cursor offengelegt, dem KI-Code-Editor, den laut Hersteller mehr als die Hälfte der Fortune 500 einsetzt. Sie tragen den Namen DuneSlide und werden als CVE-2026-50548 und CVE-2026-50549 geführt, beide mit einem CVSS-Wert von 9,8 von 10, auf der neueren Skala 4.0 sind es 9,3. Behoben sind sie in Cursor 3.0, veröffentlicht am 2. April 2026, und jede ältere Version ist betroffen.

Zum Zeitpunkt der Offenlegung war keine aktive Ausnutzung bekannt. Der Weg zur Korrektur verlief holprig. Cato meldete das Problem am 19. Februar, der Hersteller wies es am 23. Februar zunächst zurück, öffnete den Fall dann wieder, lieferte die erste Korrektur am 1. April und die zweite am 1. Juni. Die CVE-Nummern wurden am 5. Juni vergeben.

Wie eine Webseite zum Befehl wird

Die Technik ist Prompt Injection ohne Klick. Der Entwickler tippt nie eine bösartige Anweisung. Stattdessen liest der Agent Inhalte für den Nutzer: die Antwort eines angebundenen Model-Context-Protocol-Servers, eine Seite aus der Websuche oder eine Datei im Projekt. In diesen Inhalten stecken versteckte Befehle, denen das Modell anschließend folgt.

Die erste Lücke missbraucht den Parameter working_directory. Setzt der Agent ihn auf einen Pfad abseits des Standards, nimmt Cursor diesen Pfad ungeprüft in die Liste der erlaubten Schreibziele auf. Eine eingeschleuste Anweisung kann so eine Systemdatei überschreiben, etwa das Sandbox-Hilfsprogramm oder ein Shell-Profil. Die zweite Lücke nutzt eine Symlink-Prüfung, die im Zweifelsfall durchwinkt: Kann Cursor eine Verknüpfung nicht auflösen, vertraut es dem Pfad im Projekt und schreibt direkt auf dasselbe Hilfsprogramm. Wer dieses Hilfsprogramm überschreibt, sorgt dafür, dass der nächste Befehl außerhalb der Sandbox mit allen Rechten des Entwicklers läuft.

Die Leseliste ist jetzt die Angriffsfläche

Die unbequeme Verschiebung betrifft das, was als Eingabe zählt. Jahrelang bestand das Bedrohungsmodell eines Code-Editors aus dem Code, den man selbst schrieb, und den Erweiterungen, die man installierte. Ein autonomer Agent weitet es auf alles aus, was er von sich aus liest: die README einer Abhängigkeit, eine Werkzeugantwort, eine abgerufene Seite. Jedes davon ist heute ausführbare Anweisung, und der Wirkungsradius ist das Betriebssystem statt eines Browser-Tabs.

Für ein Unternehmen, das KI-Programmierassistenten an seine Entwickler ausgerollt hat, wird das Werkzeug damit zu einem Bestandteil der Lieferkette mit Zugriff bis auf die Maschine, nicht zu einem Produktivitäts-Plugin. Unter NIS2 in der EU und den gleichwertigen Pflichten, die britische Unternehmen längst tragen, ist die Sicherheit der Software, die Sie an Ihre Belegschaft verteilen, Sache der Geschäftsleitung, und ein ungepatchter Agent, der ungeprüften Inhalten vertraut, fällt genau in diese Pflicht.

Was Inhaber diese Woche tun sollten

Der erste Schritt ist Versionshygiene. Prüfen Sie, dass jeder Entwickler auf Cursor 3.0 oder neuer arbeitet, denn nichts davor ist sicher, und stellen Sie dieselbe Frage für jeden weiteren agentischen Editor und IDE-Assistenten im Einsatz. Klären Sie, welche KI-Werkzeuge eigenständig Dateien schreiben oder Befehle ausführen dürfen und wer das freigegeben hat.

Der dauerhafte Schritt ist, die Lesequellen eines Agenten grundsätzlich als nicht vertrauenswürdig zu behandeln. Begrenzen Sie, welche Model-Context-Protocol-Server ein Team anbinden darf, halten Sie Agenten so weit wie möglich von ungeprüften externen Inhalten fern und verlangen Sie eine menschliche Freigabe für Schreibzugriffe außerhalb des Arbeitsprojekts. Das Werkzeug ist es wert, behalten zu werden. Die Rechte darum herum brauchen jetzt dieselbe Disziplin, die Sie längst auf jede Komponente anwenden, die eine laufende Maschine berühren kann.

Weiterlesen: Eine KI führte einen ganzen Ransomware-Angriff allein  |  29 Jahre alter Squid-Fehler gibt Klartext-Logins preis