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 nutzt. Sie tragen den Namen DuneSlide und die Kennungen CVE-2026-50548 und CVE-2026-50549, beide mit einem CVSS-Wert von 9,8 von 10, oder 9,3 auf der neueren Skala 4.0. 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 erneut, lieferte eine Korrektur am 1. April und die zweite am 1. Juni, und 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 im Auftrag des Nutzers: eine Antwort eines angebundenen Model-Context-Protocol-Servers, eine über die Websuche gefundene Seite oder eine Datei im Projekt. Dieser Inhalt trägt versteckte Befehle, denen das Modell dann folgt.

Die erste Lücke missbraucht den Parameter working_directory. Setzt der Agent ihn auf einen abweichenden Pfad, nimmt Cursor diesen Pfad ungeprüft in die Schreiberlaubnis auf, sodass eine eingeschleuste Anweisung eine Systemdatei überschreiben kann, etwa die Sandbox-Hilfsdatei oder ein Shell-Profil. Die zweite Lücke nutzt eine Symlink-Prüfung, die im Fehlerfall nachgibt: Kann Cursor eine Verknüpfung nicht auflösen, vertraut es dem Pfad im Projekt und schreibt direkt zur selben Hilfsdatei durch. Wer diese Hilfsdatei überschreibt, lässt den nächsten Befehl ausserhalb der Sandbox mit allen Rechten des Entwicklers laufen.

Die Leseliste ist jetzt die Angriffsfläche

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

Für ein Unternehmen, das KI-Assistenten an seine Entwickler ausgerollt hat, wird das Werkzeug damit zu einem Lieferketten-Bestandteil mit Zugriff bis auf die Maschine, nicht zu einem Produktivitäts-Plugin. Unter NIS2 in der EU, umgesetzt in Deutschland durch das NIS2-Umsetzungsgesetz und begleitet vom BSI, ist die Sicherheit der an Mitarbeiter verteilten Software Sache der Geschäftsleitung, und ein ungepatchter Agent, der ungeprüfte Inhalte für bare Münze nimmt, fällt genau darunter.

Was Inhaber diese Woche tun sollten

Der erste Schritt ist Versionshygiene. Stellen Sie sicher, dass jeder Entwickler auf Cursor 3.0 oder neuer ist, denn alles davor ist unsicher, und stellen Sie dieselbe Frage für jeden anderen agentischen Editor oder 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 wo möglich von ungeprüften externen Inhalten fern und verlangen Sie menschliche Freigabe für Schreibvorgänge ausserhalb des Arbeitsprojekts. Das Werkzeug ist es wert, behalten zu werden; die Rechte darum herum brauchen jetzt dieselbe Disziplin, die Sie ohnehin für jede Komponente anwenden, die eine laufende Maschine berühren kann.

Weiterlesen: Jailbreak-Risiko hat jetzt eine Schweregrad-Note  ·  Ihr KI-Agent vertraut einem vergifteten Tool