Cursor Marketplace Backdoor: VS-Code-Fork-Vertrauen

Ein Entwickler öffnet Cursor an einem Dienstagmorgen, sieht ein Update für die Claude-Code-Extension und lässt es installieren. Nichts wirkt anders. Die Extension lädt, der KI-Assistent funktioniert, und bis zum Mittagessen hat die Maschine einen Ed25519-Schlüssel des Angreifers in ~/.ssh/authorized_keys, einen Reverse-SSH-Tunnel, der zu einem Server im Internet verbindet, und eine LaunchAgent, die sich als Apple-Systemprozess tarnt und alles über Neustarts hinweg am Laufen hält. Das ist die Cursor-Marketplace-Backdoor, die Phorion offengelegt hat, und sie ist die bislang deutlichste Demonstration für etwas, worüber wir in der Security-Community seit Jahren murmeln: VS-Code-Forks übernehmen Microsofts Codebasis, aber nicht Microsofts Vertrauensmodell.

Ich habe einen großen Teil meiner Karriere mit Incident Response auf Entwickler-Rechnern verbracht, und dieser Vorfall geht mir nahe, weil der Verbreitungsweg so gewöhnlich war. Kein Phishing. Kein Zero-Day. Nur ein manipuliertes Extension-Paket, Versionen 2.1.312 und 2.1.313, veröffentlicht in einem Marketplace, dem Entwickler standardmäßig vertrauen, weil er genauso aussieht wie das, dem sie ohnehin vertrauen. Die eigenen Kanäle von Anthropic waren sauber – jemand hat Zugriff auf die Publishing-Pipeline von Cursor genutzt, um eine veränderte Kopie einer Extension auszuliefern, die Anthropic für diese Registry nie gebaut hatte. Der Schaden betraf jeden Cursor-Nutzer, der in einem Zeitfenster von elf Stunden automatisch aktualisiert hat.

Was die Backdoor tatsächlich tat

Der Implant war ein sofort aufgerufener Funktionsausdruck (IIFE), der dem minifizierten extension.js-Bundle vorangestellt wurde. Alles nach dem eingeschleusten Präfix sah aus wie die normale Extension – dieselben Exporte activate und deactivate, derselbe UI-Code, dieselben Strings. Das sollte Ihnen Sorgen machen, wenn Ihre Erkennungsstrategie darin besteht, das Bundle mit dem Upstream zu vergleichen: Der bösartige Teil besteht aus ein paar hundert Bytes zusätzlichem JavaScript, die oben auf einer ansonsten legitimen, megabytegroßen Datei sitzen. Er läuft in dem Moment, in dem Node das Modul lädt, noch bevor der eigene activate-Callback der Extension feuert. Der Nutzer muss nichts anklicken, Claude nicht aufrufen und nicht mit der Extension interagieren.

Die Nutzlast selbst ist ein Vier-Stufen-Job, und ehrlich gesagt ist das solide Arbeit:

• Schlüssel einpflanzen. Hängt einen vom Angreifer kontrollierten Ed25519-Public-Key, kommentiert mit svc-telemetry, an ~/.ssh/authorized_keys an, mit korrekten Berechtigungen 0700/0600.
• SSH aktivieren. Versucht sicherzustellen, dass sshd läuft – systemctl unter Linux, Remote Login unter macOS, OpenSSH-Server über PowerShell unter Windows.
• Reverse-Tunnel. Öffnet eine ausgehende SSH-Verbindung zu einem vom Betreiber kontrollierten Server mit -R *:0:localhost:22, sodass der Angreifer über den Tunnel auf Port 22 des Opfers zurückgreifen und sich mit dem eingepflanzten Schlüssel anmelden kann. Kein eigenes C2-Protokoll nötig – SSH ist das C2.
• Persistenz und Aufklärung. Ein User-LaunchAgent namens com.apple.sysmond.plist unter macOS, ein @reboot-Cron-Eintrag unter Linux, ein Fallback im Autostart-Ordner unter Windows. Dazu ein einmaliges Beacon mit Hostname, Benutzername, Git-E-Mail, öffentlicher IP und bis zu vierzig Umgebungsvariablen-Namen, die auf /KEY|TOKEN|SECRET|PASS|AWS|GCP/i passen.

Der letzte Punkt ist auf eine Weise clever, die es sich zu verstehen lohnt. Das Beacon exfiltriert nicht Ihren AWS-Secret-Key – es exfiltriert die Tatsache, dass Sie einen haben. Es ist ein Zielinventar. Der Angreifer bekommt eine Auswahl, welche kompromittierten Rechner Cloud-Engineers mit aktiven Credentials in der Umgebung gehören, und genau dorthin kehrt er zuerst über den Tunnel zurück.

Der macOS-Bug, der Menschen versehentlich geholfen hat

Hier ist das Detail, das mich als Incident Responder fast zum Lachen bringt: Der macOS-Aktivierungspfad der Malware ist durch einen klassischen Scripting-Fehler kaputt. Der Code führt systemsetup -getremotelogin als unprivilegierter Benutzer aus und versucht Remote Login nur dann einzuschalten, wenn die Ausgabe auf /Off/i passt. Unter macOS verweigert dieser Befehl aber die Ausführung ohne Administratorrechte. Er schreibt „You need administrator access to run this tool... exiting!“ auf stdout – und beendet sich mit Exit-Status 0.

// what the malware effectively does
var rl = ex("systemsetup -getremotelogin 2>/dev/null", 4000);
if (/Off/i.test(rl)) {
det("sudo -n systemsetup -setremotelogin on >/dev/null 2>&1");
}

Der Fehlertext enthält kein „Off“, also schlägt der Regex fehl, also läuft der Aktivierungsschritt nie. Das Skript behandelt „Ich habe keine Berechtigung zu prüfen, ob SSH aus ist“ als „SSH ist bereits an“. Exit-Code 0 bei einem fehlschlagenden Befehl ist eine der ältesten Fallen beim Shell-Scripting, und diesmal hat sie den Malware-Autor statt eines Sysadmins erwischt. Auf einem Mac, auf dem Remote Login nicht bereits aktiviert ist, verbindet der Reverse-Tunnel zwar problemlos nach außen, aber alles, was zurückgeleitet wird, landet an einem geschlossenen Port 22. Die Schlüssel und die Persistenz werden trotzdem abgelegt – die Maschine ist also weiterhin kompromittiert –, aber der interaktive Zugangsweg ist von Anfang an tot.

Geben Sie sich damit nicht zufrieden. Wenn der Nutzer Remote Login bereits aktiviert hatte oder es später einschaltet, wartet der eingepflanzte Schlüssel in authorized_keys nur darauf. Der Windows-Pfad hat einen ähnlichen Fehler (er leitet einen PowerShell-Befehl durch einen Helfer, der /bin/sh fest codiert), und die Cron-Logik unter Linux kann bei wiederholten Läufen die bestehende Crontab eines Nutzers löschen. Von Menschen geschriebene Malware hat menschliche Fehler. Die von nächstem Monat wird welche haben – nur andere.

Warum geforkte Marketplaces Microsofts Vertrauensmodell nicht erben können

Das ist der strukturelle Punkt, und genau damit sollten sich Engineering-Leads beschäftigen. Wenn Sie eine Extension aus dem offiziellen Visual Studio Marketplace installieren, steckt dahinter eine echte Pipeline: Publisher-Konten mit Domain-Verifizierung, Scans beim Veröffentlichen, Takedown-Prozesse und auf der anderen Seite ein Unternehmen mit einer Rechtsabteilung. Das ist alles andere als perfekt – bösartige Extensions sind schon durchgerutscht –, aber es ist ein System.

VS-Code-Forks wie Cursor können aus lizenzrechtlichen Gründen diesen Marketplace nicht nutzen und verweisen daher auf alternative Registries – Open VSX oder eigene Infrastruktur. Die Editor-Oberfläche ist Byte für Byte vertraut. Die Extension-Seite zeigt denselben Namen, dasselbe Icon, einen plausiblen Publisher-String. Aber jede Kontrolle, die den Original-Marketplace vertrauenswürdig gemacht hat, ist entweder neu implementiert oder fehlt ganz. Wer hat den Publisher verifiziert? Wer hat das Bundle gescannt? Wurde das Artefakt aus dem Quellrepo gebaut, das es behauptet, und können Sie das prüfen? In diesem Vorfall existierten die manipulierten Versionen offenbar nie auf der Registry von Microsoft – sie lagen nur auf der des Forks. Das Vertrauen war rein optisch.

Denselben Film haben wir in der Welt der Package-Registries schon gesehen. Die LiteLLM-PyPI-Kompromittierung funktionierte, weil der Publishing-Zugang die Schwachstelle ist, nicht der Code. Extensions sind in einem wichtigen Punkt schlimmer als Packages: Es gibt keine Lockfile-Kultur, keine Reproduzierbarkeit wie bei npm ci, kein Hash-Pinning. Der Editor aktualisiert sich stillschweigend, und wie ein Kommentator auf Hacker News herausfand, gilt die Auto-Update-Verzögerung von VS Code nicht einmal für „vertrauenswürdige Publisher“ – eine Liste, die Sie nicht konfigurieren können. Ihr Extension-Set ist ein lebendiger, ungepinnter Dependency-Baum, der mit Ihren vollen Nutzerrechten läuft und sich aktualisiert, während Sie schlafen.

KI-Coding-Tools sind eine Rechteausweitung, die Sie selbst gewählt haben

Lassen Sie die Marketplace-Dramatik beiseite und schauen Sie sich an, was das eigentliche Ziel war. Eine KI-Coding-Extension ist kein Farbschema. Sie läuft mit den Rechten der IDE – also Ihren Rechten – und ihre ganze Aufgabe ist es, Ihren Quellcode zu lesen, Ihre API-Credentials zu halten und zunehmend Shell-Befehle in Ihrem Auftrag auszuführen. Als wir darüber geschrieben haben, wie agentische Coding-CLIs mit Berechtigungen umgehen, war das wiederkehrende Thema, dass der nützliche Agent und der gefährliche Agent durch Policy getrennt sind, nicht durch Fähigkeiten. Eine Extension, die child_process ausführen kann, ist nur einen bösen Publish davon entfernt, beliebigen Code auszuführen.

Ein Kommentator hat es unverblümt gesagt: Alle, die diese Tools nutzen, betreiben im Grunde täglich curl-pipe-bash, und wir haben junge Entwickler jahrelang davor gewarnt. Das ist übertrieben, aber nur ein bisschen. Der Unterschied zwischen curl | bash und einer sich automatisch aktualisierenden agentischen Extension besteht darin, dass die Extension eine hübschere Oberfläche hat. Ich habe schon mehrfach argumentiert, dass CLI-Tools standardmäßig keine Hintergrund-Daemons installieren sollten; dieser Vorfall zeigt, was passiert, wenn der Daemon von jemand anderem installiert wird und Sie nie zugestimmt haben. Ein losgelöster SSH-Prozess, der das Beenden der IDE überlebt, ist genau das Verhaltensmuster, das ich in Reviews markiere – und hier wurde es von einem Angreifer über einen vertrauenswürdigen Update-Kanal ausgeliefert.

So prüfen Sie Ihre Flotte jetzt

Wenn in Ihrer Organisation irgendjemand Cursor nutzt, behandeln Sie das als laufenden Vorfall, nicht als Nachricht. Die aussagekräftigen Indikatoren, direkt aus dem forensischen Bericht:

# macOS / Linux: the planted key is the cleanest signal
grep -s svc-telemetry ~/.ssh/authorized_keys && echo "IMPACTED" || echo "key not found"
# Check persistence artifacts
ls ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null   # macOS
ls ~/.config/.smt ~/.config/.smtk 2>/dev/null                   # macOS + Linux
crontab -l 2>/dev/null | grep -F .smt                           # Linux @reboot entry
# Windows (PowerShell): check both authorized_keys locations
Select-String svc-telemetry "$HOME\.ssh\authorized_keys",
"C:\ProgramData\ssh\administrators_authorized_keys" -ErrorAction SilentlyContinue
# Live tunnel: look for detached ssh with remote forwarding
ps aux | grep -E 'ssh.*-R' | grep -v grep

Ein paar Hinweise zur Suche aus eigener Erfahrung. Erstens: Prüfen Sie den Schlüssel-Fingerprint, nicht nur den Kommentar – der Implant dedupliziert anhand des Kommentars svc-telemetry, und ein Bereinigungsversuch könnte es genauso tun. Zweitens: Die Tunnel-Schlüsseldatei liegt im temporären Verzeichnis mit einem Namen wie .stk_, gefolgt von zehn Hex-Zeichen, die aus einem MD5 von Hostname plus Home-Pfad abgeleitet sind. Sie ist pro Rechner deterministisch, sodass Sie den genauen Dateinamen berechnen und danach suchen können. Drittens: EDR-Prozesstelemetrie zeigt den macOS-Aktivierungsversuch für Standardnutzer nicht, weil der Bug dafür sorgt, dass er nie ausgeführt wird. Dass systemsetup -setremotelogin in Ihren Logs fehlt, heißt nicht, dass keine Kompromittierung vorliegt. Der Schlüssel und die LaunchAgent sind die Ground Truth.

Wenn Sie den Schlüssel finden, bekommt die Maschine die volle IR-Behandlung: Rotieren Sie jede Credential, deren Umgebungsvariablenname gebeacont worden sein könnte (also die meisten – der Regex erfasst AWS, GCP, alles mit KEY oder TOKEN im Namen), widerrufen Sie den Zugriff der Maschine und spielen Sie sie neu auf. Löschen Sie nicht einfach den Schlüssel und betrachten Sie die Sache als erledigt. Der Angreifer hatte – oder versuchte zu erlangen – interaktiven Shell-Zugriff, und allein aus dem Code des Implants können Sie nicht auflisten, was er angefasst hat. Hier schlagen auch die blinden Flecken beim Logging der Cloud-Authentifizierung zu: Prüfen Sie Ihre Cloud-Audit-Logs auf Konsolen- oder API-Nutzung im Zeitraum zwischen dem Extension-Update und der Offenlegung, und zwar anhand der Credentials des betroffenen Nutzers.

Härtung: den Editor eindämmen, nicht nur die Extension

Nach einem Vorfall fragt jeder, was man ändern sollte. Meine Position, und ich verteidige sie: Sie werden sich nie durch Audits zu einem sicheren Extension-Ökosystem arbeiten, also müssen Sie eindämmen. Den allgemeinen Zielkonflikt haben wir in Containment vs. Monitoring bei KI-Agenten behandelt, und dieser Vorfall ist der Containment-Fall in Reinform. Monitoring hat Ihnen hier nichts gesagt, bis eine Sicherheitsfirma von außen das Bundle zerlegt hat.

• Extension-Versionen pinnen und Auto-Update deaktivieren für alles mit weitreichenden Berechtigungen – und dieselbe Regel auch für Forks anwenden. Ja, Sie erben damit Update-Müdigkeit. Das ist billiger als Incident Response.
• Egress-Filterung auf Entwickler-Workstations. Das gesamte Zugriffsmodell hing an einer ausgehenden SSH-Verbindung zu einer VPS-IP. Wenn Ihre Dev-Rechner keinen beliebigen ausgehenden Port 22 öffnen können, stirbt die Tunnel-Stufe. Kaum jemand macht das, und es hätte dieses Implant vollständig entschärft.
• SSH-Status als Canary überwachen. Alarmieren Sie, wenn Remote Login aktiviert wird, neue Schlüssel in authorized_keys auftauchen oder sshd-Prozesse auf Rechnern laufen, die keinen sshd brauchen.
• Ihre KI-Tools so inventarisieren wie Server. Wissen Sie, welche Extensions und Agent-CLIs freigegeben sind, welche Berechtigungen sie haben und aus welchem Marketplace sie stammen. Wenn die Antwort auf „Welche Registry nutzen unsere Cursor-Installationen?“ ein Achselzucken ist, ist das Ihr Projekt für das nächste Quartal.
• Agenten bevorzugen, die, wo möglich, in Sandboxes oder Containern laufen, mit Credentials, die pro Sitzung injiziert werden, statt dauerhaft in der Umgebung zu liegen – das Scraping von Umgebungsvariablen durch das Beacon funktioniert genau deshalb, weil wir Secrets in Prozessumgebungen herumliegen lassen.

Ein Extension-Marketplace ohne eigene Verifizierungs-Pipeline ist kein Marketplace, sondern ein Dateihoster mit Installationsbutton.

Die unbequeme Schlussfolgerung

Anthropic wurde nicht gehackt. Der Marketplace von Cursor schon, und Anthropics Marke hat den Schaden trotzdem abbekommen, weil die Extension für Entwickler das Produkt ist, unabhängig davon, wer welchen Build veröffentlicht hat. Das ist die Ökonomie geforkter Ökosysteme: Der billigste Weg, ein wertvolles Ziel zu treffen, ist, die schwächste Registry anzugreifen, der die Nutzer dieses Ziels vertrauen. KI-Coding-Assistenten liegen genau am perfekten Schnittpunkt – riesige Installationsbasis, maximale lokale Rechte, Credentials überall und eine Lieferkette, die ihre Artefakte über Registries mit völlig unterschiedlicher Sicherheitslage forkt und neu hostet.

Dieser Vorfall endete damit, dass die manipulierten Versionen nach etwa elf Stunden entfernt wurden, und ein macOS-Bug begrenzte den Schaden. Die Reaktion war in Ordnung. Das Problem ist die Architektur, und die hat sich nicht geändert: Ihr Editor ist ein Paketmanager, der alles, was er installiert, als Sie selbst ausführt, sich still aktualisiert und in einer wachsenden Zahl von Setups seine Pakete aus einer Registry bezieht, die in Ihrem Security-Team nie jemand bewertet hat. Schließen Sie die Egress-Regeln, pinnen Sie die Extensions und inventarisieren Sie die Agenten. Der nächste Publisher-Kompromiss wird keinen Regex-Fehler haben, der Ihre Nutzer rettet.