Nicht das Modell wurde gehackt. Die Umgebung, der wir unsere Entwicklungsrechte geben.

Ok, gleich vorweg, weil es die erste Frage ist: Wir arbeiten mit Cursor, und wir waren nicht betroffen. Geprüft, nicht gehofft. Und jetzt der Fall, weil er wichtiger ist als die Schlagzeile. Am 29. Oktober lag im Cursor Marketplace eine Version der Claude-Code-Erweiterung, die nicht von Anthropic kam. Gleicher Name, gleiche Kennung, gleiche Funktion. Nur standen 66 Zeilen davor, die einen fremden SSH-Schlüssel eintragen, einen Rückkanal öffnen und Rechnerdaten verschicken. Kein Prompt, kein Modell, keine Halluzination. Der ganze Vorfall hat mit KI nur eines zu tun: dass wir diesen Werkzeugen Rechte geben, die wir sonst niemandem geben würden.

Was passiert ist

Version 2.1.313 der Erweiterung „anthropic.claude-code" erschien am 29. Oktober morgens im Cursor Marketplace, als reguläres Update unter der echten Herausgeberkennung. Wer Auto-Update eingeschaltet hatte, bekam sie. Vor dem legitimen Code der Erweiterung sass ein Loader von 66 Zeilen. Der lief beim Start des Editors, man musste Claude nicht einmal benutzen. Er trug einen Schlüssel mit dem harmlosen Namen „svc-telemetry" in die Datei „authorized_keys" ein, versuchte den lokalen SSH-Dienst einzuschalten, baute einen Rückkanal zu einer festen IP-Adresse auf, installierte Persistenz, je nach System als geplante Aufgabe, Crontab oder LaunchAgent, und schickte Rechnerdaten unverschlüsselt an einen Beacon auf Port 8099: öffentliche IP, Hostname, Benutzername, System, Git-E-Mail, und die Namen von bis zu vierzig Umgebungsvariablen, in denen KEY, TOKEN, SECRET, PASS, AWS oder GCP vorkommt. Nicht die Werte. Aber die Namen reichen, um zu wissen, welche Cloud, welches CI, welche Art von Zugang auf diesem Rechner liegt.

Elf Stunden später, um 13:35 Uhr pazifischer Zeit, war die Version weg. Cursor hat den Marketplace vorübergehend ganz abgeschaltet, nach weiteren manipulierten Erweiterungen gesucht und keine gefunden. Anthropic hat 2.1.314 auf Open VSX und den Microsoft Marketplace geschoben. Beide waren nie betroffen, auch das npm-Paket nicht. Nur Cursors eigener Marketplace.

Die Kette, und wo das Modell darin vorkommt: nirgends

Wir reden seit einem Jahr über Prompt Injection, vergiftete Trainingsdaten, Agenten, die driften. Hier brauchte der Angreifer nichts davon. Kein einziger Modellaufruf war nötig. Das ist die Sicherheitsfrage, die mich seit dem Binance-Vorfall nicht loslässt, und sie ist hier dieselbe: Wer kontrolliert den ausführbaren Code rund um das Modell? Ein Agent kann vollständig korrekt arbeiten, jede Regel einhalten, sich nie selber abnehmen, und im selben Prozess sammelt eine kompromittierte Erweiterung bereits Zugangsdaten. Die Werkzeuge, denen wir Entwicklungsrechte geben, Editor, Erweiterungen, MCP-Server, Agenten-Tools, sind die Angriffsfläche. Nicht das Modell.

Wie gross der Schaden war

Laut Cursor höchstens 5'000 Nutzer, die in dem Fenster installiert oder aktualisiert haben. Und ein Stück Glück, das man nicht als Sicherheit verbuchen darf: Den lokalen SSH-Dienst einzuschalten braucht Admin-Rechte, die die Erweiterung auf den meisten Macs und Windows-Rechnern nicht hatte. Dort scheiterte der Schritt, und der Angreifer konnte sich nicht durch den Tunnel anmelden. Der Schlüssel war trotzdem drin, die Persistenz auch, und die Rechnerdaten waren unterwegs. Wer die Erweiterung einfach deinstalliert hat, hat den Schlüssel und die Persistenz behalten. Das ist der Punkt, an dem die meisten aufhören, und genau der, an dem es anfängt.

Wie man prüft, lesend

Cursor hat eine offizielle Anleitung mit Bereinigungsschritten veröffentlicht, verlinkt unten, und die ist die Referenz. Was ich hier zeige, ist der erste Blick, nur lesend, nur mit den Indikatoren, die öffentlich bestätigt sind. Für macOS und Linux:

#!/bin/bash
# Nur lesen. Ändert nichts.
echo "[1] Fremder SSH-Schluessel?"
grep -n 'svc-telemetry' "$HOME/.ssh/authorized_keys" 2>/dev/null \
  && echo "ALARM: Schluessel gefunden" || echo "kein bekannter Schluessel"

echo "[2] Manipulierte Erweiterung installiert?"
for d in "$HOME/.cursor/extensions" "$HOME/.vscode/extensions"; do
  [ -d "$d" ] && find "$d" -maxdepth 1 -iname 'anthropic.claude-code-2.1.313*' -print
done

echo "[3] Spuren der Adresse im Code oder in Prozessen?"
grep -rl '134\.209\.82\.225' "$HOME/.cursor/extensions" 2>/dev/null
ps -axo pid,command | grep '134\.209\.82\.225' | grep -v grep

echo "[4] Persistenz: alles ansehen, was seit dem 29.10. neu ist"
ls -lat "$HOME/Library/LaunchAgents" 2>/dev/null | head
crontab -l 2>/dev/null
echo "fertig"

Keine Treffer sind beruhigend, aber kein Beweis. Ein Treffer heisst: Rechner vom Netz, nichts löschen, bevor man es gesichert hat, dann Cursors Anleitung, dann alle Zugangsdaten erneuern, die dieser Rechner erreichen konnte. SSH-Schlüssel, Tokens, Cloud-Zugänge, Sessions. Nicht nur die, deren Namen im Beacon standen. Alle.

Finden reicht nicht. Entfernen und beweisen.

Das ist die Stelle, an der ich über die üblichen Sicherheitsartikel hinaus will. Erkennen, dass eine Erweiterung kompromittiert war, ist der kleinste Teil. Die Arbeit hat drei Teile, und bei uns heisst das jetzt so:

Was ich daraus baue: ein Security Guard

Ich habe nach den 169 Dateien geschrieben, dass eine Leitplanke zu 95 Prozent keine ist. Hier ist die nächste Leitplanke, die wir nicht hatten: Niemand hat bei uns beobachtet, was die Werkzeuge um die Agenten herum tun. Die Agenten ja. Die Werkzeuge nein. Also bauen wir das, als eigenen Dienst in NeoCoder, und ich beschreibe ihn als Plan, nicht als Produkt.

Der Unterschied zu einem Virenscanner ist der zweite Punkt. Ein Virenscanner kennt Listen. Wir kennen, wie sich unsere Werkzeuge normalerweise verhalten, weil wir ohnehin alles mitschreiben, was im Projekt passiert. Eine Erweiterung, die plötzlich in authorized_keys schreibt, fällt an der Abweichung auf, nicht an der Signatur. Und das Ganze läuft lokal, ohne Cloud, weil ein Security-Dienst, der zum Prüfen erst nach Hause telefonieren muss, dasselbe Problem hat wie der Loader.

Die Grenze, die man benennen muss

Was offen ist

Vor allem, wie der Angreifer unter der echten Herausgeberkennung im Cursor Marketplace veröffentlichen konnte. Cursor sagt, die Version sei nicht von Anthropic entwickelt worden, und der genaue Weg ist nach eigener Aussage noch unklar. Ob die Rechnerdaten irgendwo weiterverwendet wurden, weiss niemand öffentlich. Und ob alle 5'000 den Schlüssel wieder entfernt haben, auch nicht. Das Fenster war elf Stunden. Die Folgen können länger dauern.

Was bleibt

Dieser Vorfall zeigt keine neue Schwäche von Sprachmodellen. Er zeigt, wie lang die Vertrauenskette geworden ist, an der ein Entwicklerrechner hängt: Marketplace, Herausgeberkennung, Erweiterung, Editor, Betriebssystem, SSH, Cloud-Zugänge, Firmeninfrastruktur. Ein Glied davon reicht. Ich habe beim Binance-Vorfall geschrieben, dass Fehler finden einfach geworden ist. Hier hat jemand nicht einmal einen Fehler gebraucht. Er hat eine Datei durch den vorgesehenen Kanal geschoben und gewartet, bis die Auto-Updates sie geholt haben.

Quellen