Hot Tracking 031 | Backdoor in Claude-Code-Erweiterung auf Cursor

Am 30. Oktober veröffentlichte das Sicherheitsunternehmen Phorion einen Supply-Chain-Angriff auf den eigenen Extension-Markt von Cursor: Zwei Versionen der offiziellen Claude Code-Extension von Anthropic wurden mit Backdoors versehen, wodurch etwa 5000 Nutzer in Gefahr gerieten. Die damit verbundenen Diskussionen erreichten schnell die Spitze der Hacker News-Liste. Bis zu diesem Tag gab es bereits etwa 908 Upvotes und 533 Kommentare, wobei der Fokus auf der Frage lag: „Warum führt das Überprüfungssystem für den Extension-Markt dazu, dass echte Publisher IDs böse Updates veröffentlichen?“ Für viele Entwickler, die Claude Code als täglichen AI-Programmierhilfsmittel nutzen, ist dieser Vorfall eine Warnung für die Supply-Chain-Sicherheit und bietet eine Gelegenheit, die Vertrauensgrenzen des Entwicklungsumfelds neu zu bewerten. Dieser Beitrag basiert auf dem Bericht von Phorion, der Sicherheitsmitteilung von Cursor und den Antworten von Anthropic-Mitarbeitern auf Hacker News. Die genauen technischen Details richten sich nach den offiziellen Endbeschreibungen.

Was geschah

Die bösen Versionen waren anthropic.claude-code 2.1.312 und 2.1.313. Die Verteilung erfolgte über Cursor’s eigenes VS Code Extension Marketplace, nicht über das offizielle VS Code Marketplace oder OpenVSX. Die Ausbreitungszeit von Cursor lag zwischen 02:27 und 13:35 Uhr PT am 29. Oktober, insgesamt etwa 11 Stunden, wodurch möglicherweise bis zu 5000 Nutzer betroffen waren.

Im Gegensatz zu gewöhnlichen Phishing- oder Namensverwechslungsangriffen wurde bei dieser Aktualisierung direkt eine legitime Publisher-ID verwendet. Die Angreifer erhielten die Berechtigung, Updates für anthropic.claude-code auf Cursor Marketplace zu veröffentlichen, ohne dass die Nutzer einen Grund hatten, daran zu zweifeln. Nachdem Phorion am 30. Oktober einen Bericht veröffentlicht hatte, bestätigte Cursor den Vorfall schnell und enthüllte die bösen Versionen. Die Ausbreitungszeit wurde tatsächlich auf weniger als eine halbe Stunde begrenzt.

Das Payload wurde bereits beim Laden des Extension-Moduls ausgeführt, früher als der normale activate-Callback, ohne dass die Nutzer interagieren mussten. Zunächst wurden der Hostname, der Benutzername, das Betriebssystem, die Architektur, die Home-Directory, der aktuelle Arbeitsordner, der globale Git-E-Mail sowie Variablennamen, die mit KEY, TOKEN, SECRET, PASS, AWS, GCP usw. übereinstimmten, gesammelt. Die gesammelten Informationen wurden in schlichtem HTTP an 134.209.82.225:8099/beacon gesendet. Anschließend fügte das Payload die öffentliche Ed25519-Publichkeitszugangsdaten des Angreifers unter der Anmerkung „svc-telemetry“ zu ~/.ssh/authorized_keys hinzu und versuchte, den lokalen SSH-Dienst zu starten sowie einen Rückkopplungs-SSH-Tunnel zum gleichen Server zu erstellen. Um langfristig im System zu bleiben, wurde auf macOS LaunchAgent eingefügt, auf Windows eine Scheduled Task erstellt und mit Startup-Skripten unterstützt, auf Linux das crontab verwendet, wobei die Hintergrundskripte alle etwa 60 Sekunden den Tunnel wiederholt versuchten zu aktivieren.

Dabei erfordert die Inbetriebnahme der lokalen SSH-Dienst Administratorrechte. Unter normalen Rechten ist es schwierig, einen Reverse Shell zu aktivieren. Doch Informationen sammeln, SSH-Public-Keys einzubauen und persistente Zugriffe können unter niedrigeren Rechten durchgeführt werden. Das bedeutet, dass selbst wenn der Benutzer den Editor mit normalen Rechten verwendet, die Informationen des Hosts möglicherweise bereits weitergegeben wurden und ein Backdoor hinterlassen wurde. Für Entwickler, die Claude Code verwenden, kann der bösartige Code bereits im Moment des Öffnens des Projekts Informationen sammeln. Noch problematischer ist, dass VS Code-Erweiterungen im Node.js-Hauptprozessumfeld laufen und theoretisch Module wie fs, child_process und net aufrufen können. Wenn dieser hohe Rechtekontext von bösartigem Code genutzt wird, bedeutet das fast, dass beliebiger Code lokal ausgeführt werden kann. Phorion konnte den beacon Server lokalisieren, weil Payload offene HTTP-Verbindungen verwendet und die Infrastruktur des Angreifers direkt offen gelegt wurde. Diese nicht verschlüsselte Verbindungsmethode verringert zwar die Unsichtbarkeit des Angreifers, aber sie lässt auch viele Hosts innerhalb weniger Stunden Informationen zurückgeben.

Die offizielle Aussage stimmt nicht überein

Anthropic klärte schnell: Es handelte sich nicht um einen Einbruch in das Anthropic-System oder die Computer der Mitarbeiter. 2.1.313 wurde nie auf OpenVSX, VS Code Marketplace oder den offiziellen Kanälen von Anthropic veröffentlicht. Nur das Cursor Marketplace war betroffen. Die nächste Version wird 2.1.313 überspringen und direkt 2.1.314 veröffentlichen, um Unterschiede zu machen.

Die Maßnahmen gegen Cursor waren ebenfalls schnell: Die bösartige Version wurde entfernt, das gesamte Marketplace geschlossen, die Zugriffsprotokolle überprüft, bestätigt, dass keine weiteren Erweiterungen manipuliert wurden, die Schlüssel gewechselt und das Marketplace neu aufgebaut. Zudem wurde das Angreifer-Server abgeschaltet und aktive Unterstützung für betroffene Benutzer gewährt.

Aber Schnelligkeit bedeutet nicht, dass keine Schuld besteht. Der Schlüssel dieses Vorfalls war nicht, dass Anthropics Code geändert wurde, sondern dass die Berechtigungen des Cursor Marketplace gebrochen wurden. Der Angreifer konnte Updates als offizieller Publisher versenden, was zeigt, dass es ein Einzelschaden bei der Zugriffskontrolle und Überprüfung des Marketplaces gab. Benutzer vertrauen normalerweise auf die automatischen Updates von installierten Erweiterungen, aber sie überprüfen selten die Signatur oder den Herkunftsort. Noch problematischer ist, dass das Deinstallieren einer Erweiterung die Bedrohung nicht unbedingt beseitigt: Die persistenten Skripte liegen außerhalb des Ordners der Erweiterung, und selbst wenn die Erweiterung gelöscht wird, kann das Backdoor weiterhin laufen.

Dieser Vorfall zeigt auch ein tieferes Problem: Die Identität eines „offiziellen Publishers“ auf dem Erweiterungsmarkt entspricht nicht automatisch Sicherheit. Sobald der Veröffentlichungspunkt erobert wurde, unterscheidet sich die angezeigte Update-Hupe nicht von normalen Updates. Zwar war die Schließung des gesamten Marketplaces eine vorsichtige Maßnahme von Cursor, aber es zeigt auch, dass es nicht in kurzer Zeit möglich ist, zu erkennen, welche Publishers vertrauenswürdig sind und welche nicht. Diese „Gültigkeitskriterien“ beweisen gerade die Schwäche des vorherigen Überprüfungssystems. Die Tatsache, dass Anthropic 2.1.313 übersprang, war eher eine Versionierungsmaßnahme. Es konnte das Problem der gebrochenen third-party Marketplaces nicht lösen, sondern half nur den Benutzern, die Versionnummern der offiziellen Kanäle zu unterscheiden. Cursor hat nie erklärt, wie der Angreifer die Berechtigungen zur Veröffentlichung erhalten hat, was für die Bewertung der Ursachen des Vorfalls entscheidend ist. In einem Kontext, in dem Supply-Chain-Angriffe häufig vorkommen, reichen nur Versionnummern und die Löschung von Plattformen nicht mehr aus, um das Vertrauen der Benutzer wiederherzustellen.

Was wird in den Kommentaren gesagt

Die Diskussionen auf Hacker News drehen sich hauptsächlich um einige Fragen.

Erstens: Sind andere Kanäle sicher? Einige Kommentare besagen, dass bösartige Versionen auch in OpenVSX oder NPM vorkommen. Mitarbeiter von Anthropic lehnen dies entschieden ab; Phorion gibt an, dass die Version 2.1.313 auch aus dem VS Code/NPM entfernt wurde, aber es könnte nicht dasselbe bösartige Paket sein. Die offizielle Position beschränkt das Risiko auf den Cursor Marketplace – normale Nutzer sollten sich an die offiziellen Anweisungen halten.

Zweitens: Warum funktioniert das Überprüfungssystem nicht mehr? Komentare mit vielen Likes weisen darauf hin, dass es sich nicht um einen gewöhnlichen Typosquat- oder Fälschungsangriff handelt, sondern um einen Supply-Chain-Angriff mit legalen Publisher-IDs. Wenn Angreifer Updates an echte Erweiterungen senden können, ist es für fleißige Nutzer schwierig, dies visuell zu erkennen. Die Community ist sich einig, dass die Schließung des gesamten Marketplace durch den Cursor eine vorsichtige Maßnahme ist, aber sie zeigt auch die allgemeinen Schwächen in der Berechtigungssicherung von Drittanbieter-Märkten bei der Veröffentlichung.

Drittens: Die Vertrauensgrenzen bezüglich automatischer Updates. Viele Nutzer berichten, dass sie früher die automatische Aktualisierung von IDE-Erweiterungen ohne Bedingungen zuließen, weil der offizielle Publisher standardmäßig vertrauenswürdig war. Nach diesem Vorfall diskutieren mehr Menschen, ob man die automatische Aktualisierung ausschließen, die Versionen manuell überprüfen oder darauf warten, dass Hersteller stärkere Signaturverifizierungen bereitstellen. Einige Kommentare weisen darauf hin, dass solche Risiken nicht nur bei Cursor bestehen, sondern jeder Drittanbieter-Markt, der auf der VS Code-Ökologie basiert, möglicherweise Probleme hat – der Schlüssel liegt darin, ob die Fähigkeit besteht, Identität und Integrität in jeder Phase des Veröffentlichungsprozesses zu überprüfen.

Viertens: Mitgefühl und Sorgen für betroffene Nutzer. Einige Kommentare weisen darauf hin, dass viele Entwickler in ihren Arbeitsrechnern große Mengen an Schlüsseln, API-Token und Produktionsumgebungskonfigurationen speichern. Wenn SSH-Hosts eingebettet werden, kann die Auswirkung weit über eine einzelne Erweiterung hinausgehen. Andere erinnern daran, dass normale Entwickler keine Sicherheitsexperten sind und es unrealistisch ist, jeden Nutzer zu veranlassen, Erweiterungsupdates manuell zu überprüfen. Letztendlich muss die Plattform weiterhin zuverlässigere Veröffentlichungssicherheit bieten.

Fünftens: Aufforderungen an das Supply-Chain-Sicherheitssystem. Einige Nutzer erwähnen, dass ähnliche Vorfälle im Software-Supply-Chain bereits mehrfach stattgefunden haben – von npm über PyPI bis hin zum VS Code-Erweiterungsmarkt. Das Kernproblem ist immer die zu niedrige Veröffentlichungsbarriere und die zu hohen Betriebsrechte. Die wichtigsten Vorschläge umfassen: zwingende Zweifach-Authentifizierung am Publisher-Ende, Signierung der Erweiterungspakete, Content-Audits auf dem Marketplace sowie ein minimalistisches Berechtigungsmodell im Laufzeitbereich. Ob diese Vorschläge von Cursor und anderen Märkten akzeptiert werden, wird den Zustand des Vertrauens der Entwickler in Drittanbieter-Märkte zukünftig direkt beeinflussen.

Drei Dinge, die normale Nutzer tun können

1. Bestätigen Sie die Quelle und die Version der Installation. Öffnen Sie das Erweiterungspanel von Cursor oder VS Code und überprüfen Sie die Versionnummer von anthropic.claude-code. Wenn Sie am 29. Oktober zwischen 02:27–13:35 PT eine Version 2.1.312 oder 2.1.313 aus dem Cursor Marketplace installiert oder aktualisiert haben, gilt dies als hohes Risiko. Wenn Sie sich nicht an die Quelle erinnern, überprüfen Sie, ob der Publisher-Feld der Erweiterung anthropic.claude-code ist, und schauen Sie sich den Installationslog oder die Marktgeschichte an. Für andere Erweiterungen wird auch empfohlen, nach diesem Zeitpunkt nach verdächtigen Updates zu suchen. Falls Sie unsicher sind, können Sie die automatische Aktualisierung vorerst deaktivieren und stattdessen Versionen aus offiziellen Quellen manuell installieren. Cursor-Nutzer können auf der Detailsseite der Erweiterung die Quelle der Installation sehen. Wenn „Marketplace“ als eigene Quelle von Cursor angezeigt wird, sollten alle Personen, die in diesem Zeitraum aktualisiert wurden, prüfen.

2. Überprüfen Sie die verbleibenden Daten auf dem Host. Achten Sie besonders darauf, ob im ~/.ssh/authorized_keys ein Ed25519-Public-Key mit der Beschriftung svc-telemetry vorhanden ist; überprüfen Sie, ob in den ~/.config-/Ordnern verdächtige Dateien wie .smt, .smtk, smt.cmd usw. existieren; gleichzeitig suchen Sie nach Netzwerkverbindungen zu 134.209.82.225:8099. Auf macOS sollten Sie auch den ~/Library/LaunchAgents-Ordner überprüfen, auf Windows die Taskplaner und Startfälle, und auf Linux den crontab sowie die systemd user-Einheiten, um sicherzustellen, dass keine verdächtigen Einträge vorhanden sind. Sollten Sie unbekannte LaunchAgents oder Planungsaufgaben finden, sollten Sie auch diese deaktivieren und die Herkunft ermitteln, selbst wenn der Name normal erscheint. Nach der Reinigung wird empfohlen, einen Neustart durchzuführen, um zu sehen, ob verdächtige Prozesse oder Startaufgaben wieder auftreten.

3. Entfernen Sie die Erweiterungen nicht einfach nach der Reinigung. Da persistente Skripte außerhalb des Erweiterungsordners weiterhin existieren, empfehlen wir betroffenen Nutzern, die SSH-Schlüssel, Cloud-Credentials sowie wichtige Accounts und Passwörter zu wechseln und bei Bedarf den Host neu zu erstellen. Für Maschinen, bei denen nicht festgestellt werden kann, ob persistente Software eingeschleust wurde, ist es besser, übermäßig vorsichtig zu sein als Hoffnung zu haben. Wenn auf dieser Maschine Produktcode läuft oder sensible Schlüssel verwendet wurden, sollten Sie zunächst die Maschine isolieren und das System neu installieren, anstatt einfach die Erweiterungen zu löschen und weiterzumachen. Unternehmensnutzer sollten auch die CI/CD-Streams, Docker-Image-Buildern und gemeinsam genutzten Entwicklungsmaschinen überprüfen, um eine Ausbreitung zu verhindern. Schließlich wird empfohlen, dieses Ereignis in die Notfallübungen des Teams einzubeziehen, um eine weiße Liste für Erweiterungen und Prozesse zur Schlüsselrotation festzulegen. Vor der Neuinstallation sollten Sie zunächst die notwendigen Projektkodierungen und Konfigurationsdateien exportieren und vermeiden, Einstellungsordner aus der Sicherungskopie wiederherzustellen, die möglicherweise infiziert sind.

Schlussfolgerung

Das Claude Code-Hintertür-Ereignis ist kein einfaches Mal von einer bösartigen Erweiterung, sondern ein typisches Beispiel für einen Durchbruch in der Lieferkette des Drittanbieter-Marktes für Erweiterungen. Die offiziellen Kanäle und Code-Reposen von Anthropic sind nicht verloren gegangen; was verloren gegangen ist, ist die Kontrolle über die Identität der Publisher durch den Cursor Marketplace. 5000 Nutzer, ein Zeitfenster von 11 Stunden, sofortige Aktivierung des Moduls – diese Zahlen zeigen, dass in einer Umgebung mit hoher Berechtigung wie Erweiterungen für IDEs, sobald die Automatische Aktualisierung nicht mehr funktioniert, die Folgen schnell zunehmen können.

Die aktuellen schädlichen Versionen sind aus dem Verkauf genommen worden, der Marketplace wurde neu aufgebaut und die Angreifer-Server sind offline gegangen. Doch das ist nur der Anfang der Ereignisbearbeitung – nicht der Beginn des Verschwindens des Risikos. Für normale Nutzer ist die wichtigste Lehre: Die Erweiterung des Marktes und automatische Updates sind nicht von Natur aus vertrauenswürdig. Bei Bedarf muss man zu lokalen Beweisen zurückkehren, um Urteile zu fällen. Zweifel zu haben, Protokolle aufzubewahren und Schlüssel regelmäßig zu wechseln, ist die praktischste Selbstverteidigungsstrategie für Entwickler in der aktuellen Erweiterungsökologie. Für die Branche zeigt dieser Vorfall erneut, dass Sicherheit in der Lieferkette nicht nur von der Reaktionsgeschwindigkeit der Hersteller abhängt, sondern auch von soliden Designentscheidungen bezüglich Berechtigungen zum Veröffentlichen, Signaturverifizierung und Isolierung während der Ausführung. Beim nächsten Mal könnte jede beliebige populäre Erweiterung angegriffen werden; das eigentliche Problem ist nicht, wie schnell schädliche Pakete laufen können, sondern ob unsere Entwicklungsumgebung weiterhin jedem Update unterstützt, das sich als offiziell ausgibt. In einer Zeit, in der AI-Programmierhilfen immer tiefer in die Entwicklungsumgebung eindringen, ist dieses Vertrauensproblem wert, immer wieder hinterfragt zu werden.

Referenzquellen

• Phorion Blog: Official Claude Code VSIX Compromise (2026-10-30)
• Cursor Sicherheitsmitteilung (2026-10-29)
• Hacker News Diskussion: Claude Code Erweiterung mit Backdoor auf Cursor Marketplace
• Antwort von Anthropic-Mitarbeitern auf Hacker News

Unterschrift: Yongliang