Manipulierte Claude-Code-Erweiterung in Cursor: Was ein Editor-Plugin auf einem Admin-PC sieht

Kurz gefasst: Am 29. Oktober 2026 lieferte der Cursor-Marktplatz zwischen 02:27 und 13:35 Uhr pazifischer Zeit (11 Stunden 8 Minuten) die Claude-Code-Erweiterung in den Versionen 2.1.312 und 2.1.313 mit Schadcode aus. Der Code legte einen fremden SSH-Schlüssel an, versuchte einen umgekehrten Tunnel und meldete Rechnerdaten nach außen. Die erste Handlung heute: auf jedem Rechner mit Cursor nach der Zeichenkette svc-telemetry in authorized_keys suchen. Unser Befund vom 5. November: kein Treffer, und Cursor hat auf unserem Arbeits-PC gar keine Claude-Code-Erweiterung installiert.

Cursor hat am 29. Oktober 2026 eine Sicherheitsmeldung veröffentlicht. Der Marktplatz wurde kurz ganz abgeschaltet, die Schlüssel wurden rotiert, und die Server des Angreifers sind laut Cursor mit Hilfe des Hosters vom Netz genommen. Die Zahl "bis zu 5.000 Entwickler" steht bei (The Register), die Meldung von Cursor nennt keine Zahl. Wie die Fassung in den Marktplatz kam, haben bis zu unserem Stand weder Cursor noch Anthropic erklärt. Anthropic sagt, es sei kein Einbruch in die eigenen Systeme oder Laptops gewesen: Ein Angreifer habe über Zugriff auf Cursors Marktplatz eine veränderte Kopie veröffentlicht.

Für uns ist der Vorfall aus einem anderen Grund interessant als für Cursor-Nutzer allgemein. Er zeigt, wie viel ein Plugin in der Hand hat, das auf dem Rechner eines Administrators läuft. Und er lässt sich in Zahlen auf den eigenen Bestand übertragen.

Was eine Erweiterung auf einem Admin-PC darf

Eine Editor-Erweiterung ist Code, der im Erweiterungshost des Editors läuft und dieselben Rechte hat wie der Editor und das angemeldete Benutzerkonto. Laut Dokumentation von VS Code kann eine Erweiterung jede Aktion ausführen, die VS Code selbst ausführen kann. (VS Code: Extension runtime security). Für Claude-Code-Plugins sagt Anthropic dasselbe: Ein Plugin kann beliebigen Code mit den Rechten des Benutzers ausführen (Claude Code: Plugin security and trust).

Phorion, ein Endpoint-Anbieter, der den Fund laut The Register zuerst entdeckte, zeigt, wie das in diesem Fall aussah. Die Angreifer setzten dem Bundle der Erweiterung eine sofort ausgeführte Funktion voran. Sie lädt child_process, fs, os, path, http und crypto und läuft, sobald Node die Datei lädt, also vor dem normalen activate der Erweiterung (Phorion-Advisory). Das Öffnen des Editors reicht.

Cursor nennt für den Datenabfluss ausdrücklich: Rechnername, Benutzername, Betriebssystem, Architektur, Home-Verzeichnis, Namen der Umgebungsvariablen, Arbeitsverzeichnisse, die konfigurierte Git-Mailadresse und die öffentliche IP. Werte von Variablen stehen nicht in der Liste. Cursor schreibt aber auch, dass die begrenzte Sammlung späteren Zugriff über die Hintertür nicht ausschließt.

Was ein beliebiges Plugin auf einem Admin-PC erreicht, ergibt sich aus der Rechtelage und dem, was dort liegt. Bei uns liegen auf dem Arbeits-PC im Ordner .ssh ein privater Schlüssel, 61 Host-Einträge in der config und 195 Zeilen in known_hosts. Das ist eine Karte unserer Server samt Zugangsschlüssel. Ob der Schlüssel eine Passphrase hat, haben wir nicht geprüft (siehe "Noch zu messen"). Jede Erweiterung und jedes Plugin, das als unser Benutzer läuft, kann diese Dateien lesen.

Was am Zeitfenster belegt ist und was nicht

Die Zeiten aus Cursors Meldung: 02:27 bis 13:35 Uhr pazifischer Zeit am 29. Oktober, in UTC 09:27 bis 20:35 Uhr (The Register), in mitteleuropäischer Zeit also 10:27 bis 21:35 Uhr (Umrechnung von uns). Daraus folgt eine Dauer von 11 Stunden und 8 Minuten.

Das lädt zu der Aussage ein, eine Update-Verzögerung von zwölf Stunden hätte den Angriff gestoppt. Das ist eine Folgerung von uns und kein Befund. Sie braucht drei Annahmen, die keine Quelle bestätigt:

1. Der Client beachtet die Verzögerung. VS Code beschreibt extensions.autoUpdateDelay mit dem Standard 12 Stunden, 0 bedeutet sofort, und die Einstellung wirkt nur, wenn Auto-Update an ist (VS Code: Extension Marketplace). Die Release Notes zu 1.125, in denen die Einstellung eingeführt wurde, nannten damals zwei Stunden (VS Code 1.125). Welcher Wert in einer bestimmten Installation gilt, zeigt nur die Ansicht der Standardeinstellungen dieser Version.
2. Die Frist beginnt mit der Veröffentlichung im Marktplatz, nicht mit dem Zeitpunkt, zu dem der Client sie sieht.
3. Cursor folgt dieser VS-Code-Einstellung überhaupt. Die Cursor-Doku beschreibt etwas anderes: einen Install-Cooldown in Stunden, den Team-Admins setzen, Standard 0 (aus). Ist er größer als 0, gilt er flottenweit und übersteuert die persönliche Einstellung extensions.installCooldownHours (Cursor: Extensions).

Die Doku von Cursor sagt außerdem, Cooldown und Signaturprüfung seien Prüfungen auf dem Client und ersetzten nicht die Analyse im Marktplatz. Der Fall zeigt, warum: Der Schadcode kam über den Marktplatz selbst.

Wer aktualisiert sich bei uns selbst

Stand der Doku: 5. November 2026. Bei Claude Code steht zusätzlich, dass bei eingeschaltetem Auto-Update die Dateien eines geprüften Plugins im Hintergrund wechseln können.

Was wir gemessen haben

Am 5. November 2026 haben wir read-only nachgesehen. Auf dem Arbeits-PC (Windows 11, ARM64) lasen wir die Dateien extensions.json von VS Code und Cursor sowie installed_plugins.json und known_marketplaces.json von Claude Code. Auf dem code-server-Container der Appliance (VM 116, 192.168.180.206, code-server 4.145.0) haben wir per SSH die extensions.json gelesen. Geändert haben wir nichts.

Drei Einschränkungen gehören dazu. Erstens: Die Version 2.1.287 in VS Code und 2.1.316 auf dem code-server liegen nicht in der genannten Spanne 2.1.312 bis 2.1.313. Die Installation auf .206 geschah nach dem Vorfall. Nach den Dokumenten von code-server kommen dort Erweiterungen aus der Galerie Open VSX (code-server FAQ). Cursor nutzt laut eigener Doku ebenfalls Open VSX, aber über einen eigenen Proxy (Cursor: Extensions). Ob die manipulierten Versionen auch in Open VSX lagen, sagen weder Cursor noch Phorion. Wir behandeln .206 deshalb als nicht betroffen, ohne es belegen zu können. Zweitens: In known_marketplaces.json steht für unsere Marktplätze kein autoUpdate-Eintrag. Wir lesen das nach der Doku als Standard, also aus für Drittanbieter. Eine Bestätigung in der Oberfläche steht aus. Drittens: Die IOC-Hashes in Cursors Meldung nennen Pakete für darwin-arm64 und win32-x64. Unser PC ist Windows auf ARM64, und ob es dafür ein manipuliertes Paket gab, steht dort nicht.

Die Prüfung auf den Schlüssel entspricht der von Cursor:

grep -c svc-telemetry ~/.ssh/authorized_keys

Cursor liefert dafür auch eine PowerShell-Variante, die zusätzlich C:\ProgramData\ssh\administrators_authorized_keys einbezieht. Wir haben die Prüfung mit grep ausgeführt und die zweite Datei auf Existenz geprüft.

Eine Richtlinie für Pinnen und Wartezeit

Aus den Quellen und den Messungen leiten wir einen Vorschlag ab. Er ist unsere Empfehlung und keine Vorgabe eines Herstellers. Beschlossen und eingeführt ist davon bei uns nichts.

• Erweiterungen kommen aus den Marktplätzen, die der jeweilige Editor selbst vorgibt, und jeder Eintrag im Bestand bekommt Herkunft und Version.
• Auf Rechnern mit Zugang zu Servern sollte die Verzögerung bei VS Code über 0 liegen und bei Cursor der Cooldown gesetzt sein, wenn ein Team ihn verwaltet. Der richtige Wert ist offen. Er sollte länger sein als das Fenster in einem Vorfall wie diesem, ohne dass Sicherheitsupdates tagelang liegen bleiben.
• Auto-Update für Marktplätze Dritter aus lassen, das ist der dokumentierte Standard. Wer ein Plugin aktualisiert, liest vorher die Änderung. Zu den Grenzen des Commit-Pins steht Näheres in Plugin4Shell.
• Liegt ein privater Schlüssel ohne Passphrase im Home-Verzeichnis, kann jedes Plugin, das als dieser Benutzer läuft, damit Server erreichen. Ob das bei uns zutrifft, ist unten als offener Messpunkt eingetragen.

Die Themenseite Security und Datenschutz sammelt unsere Beiträge zu solchen Lieferketten. Wie Claude-Code-Plugins im Einzelnen aufgebaut sind und was ein Mod darf, steht in Claude Mods: Was das neue Plugin-Format wirklich darf. Was wir an IT-Betrieb und Absicherung anbieten, steht unter IT-Leistungen.

Belegt und offen

Belegt, mit gelesener Primärquelle:

• Versionen 2.1.312 und 2.1.313, Windows und macOS, Zeitfenster, Datenliste, Schlüsselname und Tunnelversuch: Cursor.
• Schadcode am Anfang von extension.js, Ausführung vor activate, Fehler bei der macOS-Prüfung des SSH-Dienstes, zweiter Schlüssel für den Tunnel: Phorion.
• Aussage von Anthropic, die eigenen Systeme seien nicht kompromittiert: The Register.
• Rechte von Erweiterungen und Plugins, Auto-Update-Standards und Cooldown-Einstellungen: die Dokus in der Quellenliste.

Offen sind diese Punkte:

• Wie die Fassung in den Marktplatz gelangte. Weder Cursor noch Anthropic haben es erklärt.
• Wie viele Rechner betroffen waren. Die Zahl 5.000 stammt aus der Presse ohne Herleitung.
• Ob eine Update-Verzögerung den Fall verhindert hätte. Das bleibt eine Folgerung.
• Die Versionsangaben der Berichte. The Register nennt nur 2.1.313, Cursor und Phorion nennen beide Versionen.

Noch zu messen

Diese vier Punkte haben wir nicht gemessen. Bis dahin steht hier kein Ergebnis.

1. Beachtet Cursor extensions.autoUpdateDelay, und welcher Wert gilt als Standard? Methode: in Cursor "Preferences: Open Default Settings (JSON)" öffnen und nach autoUpdateDelay und installCooldownHours suchen. Beides ist lesend.
2. Welche Variablennamen sieht der Editor-Prozess? Cursor nennt die Variablennamen als abgeflossen. Methode: im Terminal des Editors die Namen auflisten (Get-ChildItem Env: | Select Name) und gegen die Namen im normalen Terminal halten. Werte werden dabei nicht ausgegeben.
3. Hat der private Schlüssel auf dem Arbeits-PC eine Passphrase? Methode: ssh-keygen -y -P "" -f <Schlüsseldatei> gibt ohne Passphrase den öffentlichen Teil aus und meldet bei vorhandener Passphrase einen Fehler. Wir haben sie nicht ausgeführt, weil dabei der Schlüssel gelesen wird.
4. Die übrigen Hosts: Gemessen sind nur Arbeits-PC und code-server. Methode für jeden weiteren Host: extensions.json des Editors und installed_plugins.json von Claude Code lesen und in einer Liste mit Quelle, Version und Installationsdatum ablegen.

Zehn Minuten für heute

1. Auf jedem Rechner mit Cursor oder VS Code: grep -c svc-telemetry ~/.ssh/authorized_keys (Windows: Cursors PowerShell-Befehl). Erwartung: 0.
2. Version von anthropic.claude-code in jedem Editor ablesen. 2.1.312 oder 2.1.313 aus dem Cursor-Marktplatz heißt: Cursors Aufräumskript laufen lassen und Zugangsdaten rotieren.
3. In den Einstellungen nach autoUpdateDelay und installCooldownHours sehen und notieren, was dort steht.
4. claude plugin list ausführen und für jedes Plugin die Herkunft notieren.

Alle Quellen zuletzt geprüft am 5. November 2026.

Weiterführende Quellen

• Cursor: Security notice, 29.10.2026, Versionen, Zeitfenster, Prüfbefehle und IOC-Liste
• Phorion: Official Claude Code Extension Compromise, Analyse des Bundles, Stand 31.10.2026
• The Register, 30.10.2026, Aussage von Anthropic und die Zahl 5.000
• VS Code: Extension runtime security, Rechte des Erweiterungshosts
• VS Code: Extension Marketplace, Auto-Update und autoUpdateDelay
• Cursor: Extensions, Cooldown, Allowlist und Signaturprüfung
• Claude Code: Plugin security and trust, Rechte und Updates von Plugins
• Claude Code: Install and manage plugins, Auto-Update-Standards je Marktplatz