Zum Inhalt springen
senn-techsenn-tech
Zurück zum Blog
ClaudeSecurity
Security und Datenschutz2026-10-31· Von Franz Senn

Claude Code in Cursor unterwandert: elf Stunden bis zur Sperrung

Wer Claude Code in Cursor benutzt, bekommt die Erweiterung nicht von Anthropic. Er bekommt sie aus dem Marktplatz des IDE-Anbieters, und dieser Marktplatz war am 29. Oktober 2026 das Einfallstor. Cursor meldet selbst einen Angriff auf sein Erweiterungssystem: anthropic.claude-code, Version 2.1.312 und 2.1.313, war zwischen 09:27 und 20:35 UTC mit einer Payload erhältlich, die einen fremden Schlüssel in die SSH-Autorisierung schreibt und einen Tunnel nach außen aufbauen will. Microsoft, StepSecurity und Phorion haben die Datei analysiert, Sophos stützt sich auf Phorion. Wir haben die Quellen gegengelesen, weil der Fall zwei verbreitete Annahmen infrage stellt: dass eine Marktplatz-Prüfung wie eine Schwelle wirkt und dass eine entfernte Erweiterung auch weg ist.

Was ist eine unterwanderte IDE-Erweiterung? Eine unterwanderte IDE-Erweiterung ist ein veränderter Code, den ein Angreifer unter dem Namen eines echten Herausgebers in einen Marktplatz einspielt. Sie läuft mit den Rechten des angemeldeten Benutzers. Im Fall von Claude Code in Cursor legte sie einen fremden Schlüssel in der authorized_keys ab. Dieser Eintrag gilt bei jeder SSH-Anmeldung und überlebt die Deinstallation der Erweiterung und die Sperrung des Marktplatzes.

Weitere Lieferketten-Vorfälle sammelt der Themenhub Security und Datenschutz. Ein verwandter Fall ist LiteLLM 1.107.0, wo manipulierte Pakete über PyPI und Docker Hub verteilt wurden. Wem Cursor inzwischen gehört, erklärt SpaceX hat Cursor gekauft.

Der Zeitplan, so weit ihn die Quellen hergeben

Die Berichte stammen vom 29. Oktober bis 1. November 2026 (Cursor 29.10., Update 30.10.; Phorion und StepSecurity mit späteren Überarbeitungen); wir haben sie am 5. November gegen die Quellen gelesen. Sie liefern ein veröffentlichtes Zeitfenster und einige Befunde mit unterschiedlicher Genauigkeit. Die Tabelle nennt zu jedem den Messträger. Alle Angaben stammen von den Anbietern.

EreignisZeitpunkt (Einheit: UTC)Veröffentlicht amMessträger
Schadpaket im Cursor-Marktplatz verfügbar29.10.2026, 09:27 bis 20:3529.10.2026 (Cursor), Update 30.10.2026Anbietermeldung Cursor (2:27 bis 13:35 Uhr Pazifikzeit, "about"); von Microsoft (mit Verweis auf Cursor), Sophos, StepSecurity und BankInfoSecurity übernommen
Analyse von Payload, Schlüsseln und Persistenz30.10.202630.10.2026Microsoft Security Blog, Phorion (Quelltext-Analyse), StepSecurity
Schätzung betroffener Benutzerbis zu 5.00030.10.2026Schätzung von Cursor, zitiert von Sophos, BankInfoSecurity (dort als Social-Media-Beitrag von Cursor) und StepSecurity; in der Cursor-Meldung selbst steht keine Zahl
Aktualisierung der Cursor-Meldung (IOCs, Versionen)30.10.2026, 18:30 (11:30 Uhr PT)30.10.2026Zeitstempel in der Cursor-Meldung

Die Pazifikzeit lag am 29. Oktober noch in der Sommerzeit (UTC minus 7 Stunden); daraus ergeben sich die UTC-Zeiten. Das offene Fenster ist damit elf Stunden und acht Minuten. Das Fenster ergibt sich als Differenz zweier Uhrzeiten, die Cursor mit "about" nennt; gemessen wurde es nicht. BankInfoSecurity schreibt von elf Stunden.

Drei Punkte wiegen mehr als die Stundenzahl:

  1. Betroffen sind zwei Versionen, 2.1.312 und 2.1.313, für Windows und macOS, im Marktplatz von Cursor. Cursor hält fest, dass die Versionen nicht von Anthropic entwickelt wurden und dass andere Erweiterungen dort nicht betroffen sind. Die Versionsnummern führen leicht in die Irre. Laut StepSecurity hat Anthropic 2.1.313 nie über die offiziellen Kanäle veröffentlicht und ist direkt auf 2.1.314 gesprungen. Die 2.1.312 auf Open VSX hat StepSecurity heruntergeladen und als sauber geprüft; sie ist ein anderes Artefakt als die 2.1.312 im Cursor-Marktplatz. Microsoft bestätigt, dass weder der Visual Studio Marketplace noch das npm-Paket @anthropic-ai/claude-code die Schadpakete ausgeliefert haben. Anthropic hat gegenüber Microsoft erklärt, die eigenen Systeme seien nicht kompromittiert.

  2. Der Schadcode steckt im Paket selbst, ein Nachladen aus fremden Depots gibt es nicht. Phorion hat die extension.js gelesen: Der Lader läuft, sobald Node die Datei lädt, also vor der normalen Initialisierung der Erweiterung. StepSecurity beschreibt die Datei als saubere 2.1.312-Bündelung mit einem rund 7 KB großen Lader davor. Eine Kontrolle, die den Code erst beim ersten Benutzerklick prüft, sieht diese Phase nach unserer Einschätzung nie.

  3. Die Bereinigung hat zwei Teile. Bleibend sind ein Ed25519-Schlüssel mit dem Kommentar svc-telemetry in der authorized_keys und die Persistenz über ein LaunchAgent (macOS) beziehungsweise eine geplante Aufgabe mit Startup-Skript als Ausweichweg (Windows). Cursor schreibt ausdrücklich, dass das Entfernen der Erweiterung nicht ausreichen kann. Nach Cursor scheitert der Schritt, der den SSH-Dienst aktiviert, in aller Regel, weil dafür Administratorrechte nötig sind und der Schadcode Fehler enthält. Microsoft gibt das als Aussage von Cursor wieder, Sophos nennt Programmierfehler. Schlüssel und Persistenz werden laut Cursor trotzdem geschrieben. Dass der Schlüssel erst nutzbar ist, wenn auf dem Rechner ein SSH-Dienst läuft, folgt aus der Funktionsweise von SSH. Eine Quelle formuliert es für diesen Fall nicht so, es ist unsere Schlussfolgerung.

Was die Zahlen noch nicht hergeben

Die Größenordnung ist eine Schätzung, und sie kommt von Cursor. Sophos schreibt, Cursor schätze bis zu 5.000 betroffene Benutzer; BankInfoSecurity und StepSecurity ordnen die Zahl ebenfalls Cursor zu, StepSecurity als dessen erste Angabe. In der Cursor-Meldung steht keine Zahl (Abruf vom 5. November 2026); laut BankInfoSecurity stammt sie aus einem Social-Media-Beitrag von Cursor. Eine gezählte Installationszahl nennt kein Bericht. Wer eine Zahl für die eigene Meldung braucht, schätzt selbst, wie viele Systeme die betroffenen Versionen erhalten haben könnten, und kennzeichnet das als Einschätzung.

Offen ist, wie die Angreifenden in das Auslieferungssystem des Marktplatzes gekommen sind. Cursor schreibt, die Versionen seien dort "made available"; den Mechanismus nennt die Meldung nicht. BankInfoSecurity zitiert Anthropic mit der Aussage, ein Angreifer habe über den Zugang zu Cursors Marktplatz eine veränderte Erweiterung veröffentlicht, an Bau, Veröffentlichung und Hosting sei Anthropic nicht beteiligt gewesen. StepSecurity zitiert Felix Rieseberg von Anthropic mit derselben Aussage. Die Berichte belegen damit nur, dass die Kontrolle versagt hat. Wo der Fehler saß, bleibt offen, ebenso eine Zuordnung zu einem Täter. Offen ist außerdem die Reichweite im Einzelfall: Ob eine Umgebung das Paket bezogen hat, steht in ihrer Endpoint-, Netzwerk- und Installations-Telemetrie. Ein Bericht des Anbieters ersetzt diese Suche nicht.

Die drei Ketten, die hier durchgeschlagen haben

Die Erweiterung allein war es nicht. Entscheidend ist die Verkettung, und jedes Glied kommt in einer KMU-IT häufig genug vor.

Kette eins: Der Name stimmt, die Herkunft nicht. Installiert wird aus dem Marktplatz der Entwicklungsumgebung. Die veränderten Versionen trugen den Namen des echten Herausgebers, deshalb findet die Prüfung des Absenders nichts Auffälliges. Auch das Versionsschema täuschte, weil 2.1.312 eine echte Nummer wiederverwendete. Verräterisch war, dass es 2.1.313 offiziell nie gab. Das lässt sich gegen den Veröffentlichungskanal des Herstellers prüfen, nicht gegen den Marktplatz.

Kette zwei: Der Einstieg sitzt im Verteiler. Der Hersteller blieb laut Anthropic (Zitat bei BankInfoSecurity und StepSecurity) unberührt, der Angriff traf den Kanal. Wer aus einem fremden Kanal installiert, prüft den Kanal; die Herkunft des Codes ist damit noch nicht belegt.

Kette drei: Rechte und Ort der Persistenz. Die Änderung liegt dort, wo ein Entwickler die meisten Rechte hat: im SSH-Pfad. Damit geraten alle Rechner ins Risiko, an die sich diese Person anmeldet, Produktionsserver eingeschlossen. Die Schwere hängt am Ziel, das dieser Pfad öffnet. Wie Rechtevergabe und Entwicklungsarbeitsplatz im Betrieb aufgesetzt werden, beschreibt unsere Seite zur IT-Infrastruktur und zum Betrieb.

Indikatoren, die Cursor und die Analysen nennen

Die Angaben stammen aus Cursors Meldung und den Analysen; wir haben keine Datei selbst untersucht.

  • Server der Angreifenden: 134.209.82.225, Ports 22 und 8099. Cursor meldet, der Server sei abgeschaltet.
  • Schlüsselkommentar svc-telemetry in der authorized_keys; Hashes der VSIX-Pakete und der extension.js stehen in Cursors Meldung.
  • Persistenz laut Cursor: unter macOS die Datei ~/Library/LaunchAgents/com.apple.sysmond.plist, unter Windows die geplante Aufgabe SysMon mit dem Ausweichskript sysmon.cmd im Startup-Ordner.
  • Linux: Cursors Liste nennt einen Cron-Eintrag mit @reboot, die Datei ~/.config/.smt und Dateien /tmp/.stk_*. Cursor führt als verteilte Pakete nur macOS und Windows auf; die Linux-Angaben stehen aber in der IOC-Liste, und Phorion beschreibt auch einen Linux-Pfad im Code.
  • Laut Kevin Beaumont (Mastodon-Beitrag, zitiert von BankInfoSecurity) entfernen die von Anthropic nachgelieferten Ersatzversionen, die automatisch eingespielt werden, die Hintertür nicht; BankInfoSecurity nennt dazu Version 2.1.314.

Vier Maßnahmen, sortiert nach Nutzen

  1. Prüfen, ob der Schlüssel da ist. Auf jedem Rechner, auf dem Claude Code in Cursor lief: grep -qs svc-telemetry ~/.ssh/authorized_keys auf macOS (so steht der Befehl in Cursors Hinweis; auf Linux ist es dieselbe Prüfung, die Übertragung ist unsere). Auf Windows nennt Cursor ein PowerShell-Snippet, das $HOME\.ssh\authorized_keys und C:\ProgramData\ssh\administrators_authorized_keys auf den Schlüsselkommentar prüft; den Hinweis zum zweiten Pfad (Windows-OpenSSH legt bei Administratorkonten Schlüssel in der Regel dort ab) fügen wir aus eigenem Wissen hinzu. Cursor stellt Abhilfeskripte für macOS und Windows bereit, die Erweiterung, Persistenz, Tunnel-Prozesse und Schlüssel entfernen und bei Restbeständen mit Fehlerstatus enden. Auf Linux zusätzlich nach dem Cron-Eintrag mit @reboot, ~/.config/.smt und /tmp/.stk_* suchen.

  2. Erlaubte Erweiterungen erzwingen. Microsoft empfiehlt im Bericht, Erweiterungen auf freigegebene Herausgeber zu beschränken und eine Installations-Abkühlung (cooldown) einzurichten; für beide Einstellungen verweist Microsoft auf Cursors Härtungsleitfaden, den wir nicht gelesen haben. Die Beschränkung auf Herausgeber hätte diesen Fall allein nicht gestoppt, denn die Veröffentlichung lief unter dem Namen des echten Herausgebers. Eine Abkühlzeit von mehr als elf Stunden hätte das Fenster nach unserer Einschätzung abgefangen. Sie wirkt vor der Infektion.

  3. Den ausgehenden Verkehr der Entwickler-Workspaces beobachten. Der Beacon dieser Payload geht als HTTP-POST auf Port 8099, zusätzlich ein Versuch auf 127.0.0.1:8099. Wer nur Modellaufrufe und Token misst, sieht davon nichts.

  4. Anmeldedaten und Sitzungen von einem vertrauenswürdigen System aus drehen. Cursor nennt das ausdrücklich: Die beschränkte Sammlung von Umgebungsvariablen (nach Cursors Angabe nur die Namen) schließt späteren Zugriff auf Anmeldedaten über die Tür nicht aus. Was auf einem betroffenen Rechner an Sitzungen und Schlüsseln lag, ist nach so einem Fund nicht mehr sauber.

Was erledigt ist und was nicht

Cursor hat die Versionen aus dem Marktplatz entfernt, den Marktplatz zusätzlich komplett heruntergefahren, Schlüssel gedreht und ihn neu aufgebaut; den Server der Angreifenden hat der Hoster laut Cursor vom Netz genommen. Damit funktionieren Rückwärtstunnel und Meldekanal nicht mehr, so schreibt es Cursor. Nicht erledigt sind der abgelegte Schlüssel und die Persistenz auf Rechnern, die das Paket in dem Fenster bezogen haben. Solange diese Prüfung auf einem Rechner aussteht, gilt er als nicht saniert.

Stand der Überarbeitung vom 5. November 2026: Wir haben die Aussagen von Cursor, Microsoft und Sophos erneut gegen die Seiten gelesen, die Zuordnung zur fehlgeschlagenen SSH-Aktivierung korrigiert und den Abschnitt zu unserer eigenen Suche gestrichen, weil wir dafür keine Messdatei vorlegen können. Zusätzlich: Das Veröffentlichungsdatum der Cursor-Meldung ist der 29.10. (Update 30.10.), die 5.000 stammen laut BankInfoSecurity aus einem Social-Media-Beitrag von Cursor, und Microsofts Hinweis auf den Härtungsleitfaden ist jetzt als Verweis gekennzeichnet.

Weiterführende Quellen

Fragen?
Woran erkenne ich die offizielle Claude-Code-Erweiterung im Cursor-Marktplatz?+

Am Absender allein nicht: Die veränderten Versionen trugen den Namen des echten Herausgebers. Prüfen lässt sich die Versionsnummer gegen den Veröffentlichungskanal von Anthropic. Eine Version 2.1.313 hat Anthropic dort nie veröffentlicht, auf 2.1.312 folgte 2.1.314 (laut StepSecurity unter Berufung auf Anthropic).

Reicht es, die Erweiterung zu deinstallieren?+

Nein. Cursor schreibt, das Entfernen der Erweiterung könne nicht ausreichen, weil die Payload eigene Persistenz-Skripte ablegt. Auch das automatische Update auf 2.1.314 entfernt die Hintertür laut Kevin Beaumont nicht. Zu prüfen sind die authorized_keys, auf macOS die LaunchAgents und auf Windows die geplanten Aufgaben.

Betrifft das auch Firmen, die Claude Code nur über die Kommandozeile nutzen?+

Nach Angaben von Microsoft haben weder der Visual Studio Marketplace noch das npm-Paket @anthropic-ai/claude-code die Schadpakete ausgeliefert. Anthropic hat gegenüber Microsoft erklärt, die eigenen Systeme seien nicht kompromittiert. Betroffen sind laut Cursor Installationen der Versionen 2.1.312 und 2.1.313 aus dem Cursor-Marktplatz unter macOS und Windows im genannten Zeitfenster.