Am 29. Oktober 2026 wurde die offizielle Claude-Code-Erweiterung im Cursor Extension Marketplace durch einen manipulierten Build mit SSH-Hintertür ersetzt. Das Zeitfenster dauerte etwa elf Stunden: von 17:27 Uhr Pekinger Zeit bis 04:35 Uhr am nächsten Tag. Betroffen waren die Versionen 2.1.312 und 2.1.313 für macOS arm64 und Windows x64. Laut Cursor haben bis zu rund 5.000 Nutzer die Erweiterung heruntergeladen oder automatisch aktualisiert.
Es handelte sich nicht um ein gefälschtes Plugin, das sich in den Marketplace eingeschlichen hatte. Das installierte Paket trug den offiziellen Namen Anthropic.claude-code; auch Oberfläche und Funktionen sahen wie gewohnt aus. Deshalb bemerkten viele Nutzer nicht, dass sie die manipulierte Version installiert hatten. Genau deshalb reicht es auch nicht, die Erweiterung zu deinstallieren oder zu aktualisieren. Der Schadcode hat bereits einen öffentlichen SSH-Schlüssel hinterlegt, ein dauerhaftes Skript für den automatischen Start eingerichtet und Hostinformationen an den Angreifer gesendet. Für die Bereinigung sind drei Dinge nötig: den Schlüssel entfernen, die Persistenz beseitigen und Zugangsdaten rotieren.
Das erwartet Sie: Dieser Artikel führt in fünf Schritten durch die Reihenfolge „Was ist zu sehen? → Was ist zu tun? → Woran erkenne ich, dass es geklappt hat?“. Auch ohne Sicherheitskenntnisse können Entwickler die Prüfung und Bereinigung in etwa einer halben Stunde durchführen – einschliesslich der Rotation des APIYI-API-Schlüssels.
Bildunterschrift: Das Angriffszeitfenster dauerte rund 11 Stunden. Version 2.1.314 war die erste saubere Version nach dem Vorfall.
Keine Panik: Was bei der manipulierten Claude-Code-Erweiterung passiert ist
Zunächst die Fakten. Alle Angaben in der folgenden Tabelle stammen aus der Sicherheitsmitteilung von Cursor und öffentlichen Stellungnahmen von Anthropic-Mitarbeitern.
| Punkt | Fakt |
|---|---|
| Vorfall | Anthropic.claude-code im Cursor-Erweiterungsmarkt wurde manipuliert und mit einer persistenten SSH-Hintertür versehen |
| Betroffene Versionen | 2.1.312 und 2.1.313 (Cursor ergänzte 2.1.312 bei der Aktualisierung der Mitteilung am 30. Oktober) |
| Plattformen | macOS (darwin-arm64), Windows (win32-x64); der Code enthält auch einen Linux-Zweig |
| Zeitraum der Exposition | 29.10., 02:27–13:35 Uhr Pacific Time, entsprechend 29.10., 17:27 Uhr bis 30.10., 04:35 Uhr Pekinger Zeit |
| Ausmaß | Laut Cursor waren möglicherweise bis zu 5.000 Nutzer betroffen. Das ist eine Schätzung der exponierten Nutzer, keine Zahl bestätigter Infektionen |
| Aktueller Stand | Die schädlichen Versionen wurden entfernt; der Marketplace wurde geschlossen, neu aufgebaut, geprüft und wieder geöffnet. Laut Cursor hat der Hosting-Anbieter den Server des Angreifers abgeschaltet |
| Bereinigte Version | 2.1.314 war die erste bereinigte Version; am 31. Oktober war 2.1.316 die aktuellste Version |
Bildunterschrift: Screenshot der Cursor-Sicherheitsmitteilung (wird bei der redaktionellen Bearbeitung ergänzt).
Als der Vorfall bekannt wurde, kursierten einige falsche Angaben. Drei Punkte sind richtigzustellen:
- Auch 2.1.312 steht auf der Liste der betroffenen Versionen. Cursor hatte zunächst nur 2.1.313 genannt und später 2.1.312 ergänzt. Wer im betroffenen Zeitraum Version 2.1.312 aus dem Cursor Marketplace installiert hat, sollte seinen Rechner ebenfalls überprüfen.
- Nur der Cursor Marketplace war betroffen. Frühe Berichte behaupteten, auch Open VSX, der Microsoft Marketplace und npm seien betroffen. Diese Angaben wurden inzwischen korrigiert. Socket prüfte die Änderungsprotokolle der Registry und fand keinen Eintrag zur Veröffentlichung oder Löschung von 2.1.313.
- 2.1.313 wurde nie über offizielle Kanäle von Anthropic veröffentlicht. Anthropic-Sicherheitsingenieur David Dworken zufolge erschien diese Version weder auf Open VSX noch im offiziellen VS-Code-Marketplace oder auf einem offiziellen Host von Anthropic. Um Verwechslungen bei den Versionsnummern zu vermeiden, sprang die nächste offizielle Version direkt auf 2.1.314.
Wer hinter dem Angriff steckt und wie die Person an Veröffentlichungsrechte gelangte, ist bislang ungeklärt. Felix Rieseberg von Anthropic sagte, dass weder Systeme von Anthropic noch Rechner von Mitarbeitern kompromittiert wurden. Stattdessen habe jemand den Zugang zum Cursor Marketplace genutzt, um die manipulierte Version zu veröffentlichen. Die Mitteilung von Cursor erklärt nicht, wie der Angreifer die Veröffentlichungsrechte erhielt. Cursor hatte im Oktober öffentliche Einreichungen für den Marketplace freigeschaltet. Ob das mit der Manipulation zusammenhängt, wurde offiziell nicht erklärt; auch dieser Artikel stellt darüber keine Vermutungen an. Für Entwickler ist es sinnvoller, zunächst den eigenen Rechner zu prüfen, statt über die Ursache zu spekulieren.
Warum auch die offizielle Claude-Code-Erweiterung manipuliert werden konnte
Die erste Reaktion vieler Menschen ist: Wie kann ein offizielles Paket Schadcode enthalten? Um das zu verstehen, lohnt sich ein Blick darauf, wie IDE-Erweiterungen ausgeführt werden. Sie laufen mit den Rechten der IDE und können Code, Umgebungsvariablen und Dateien im Benutzerverzeichnis lesen und verändern. Schon beim Laden wird ihr Code ausgeführt – ohne dass Sie einen Dialog öffnen oder die Erweiterung aktiv nutzen müssen.
Die Analyse von Phorion zeigt: Der Schadcode bestand aus einer 66 Zeilen langen, sofort ausgeführten Funktion (IIFE) am Anfang der Datei extension.js. Erst danach folgte der normale Code der Erweiterung. Sobald Node das Erweiterungsmodul lud, wurde der Schadcode ausgeführt – noch vor dem regulären activate-Callback. Die manipulierte extension.js war 3.692.922 Byte groß und damit rund 7 KB größer als die vorherige saubere Version. Sie nutzte keinen npm-postinstall-Hook. Es handelte sich also nicht um ein manipuliertes npm-Paket: Der Code im VSIX-Installationspaket war direkt verändert worden.
Ein Vergleich hilft: Es ist nicht so, als hätte jemand ein gefälschtes Medikament in eine Apotheke geschmuggelt. Vielmehr wurde eine Packung einer bekannten Marke im offiziellen Regal durch eine manipulierte Version ersetzt. Name, Verpackung und Strichcode waren echt – nur der Inhalt stimmte nicht. Deshalb half in diesem Fall auch die übliche Empfehlung nicht, auf den offiziellen Herausgeber zu achten.
Bildunterschrift: Die Backdoor-Kette umfasst sechs Schritte. Die Deinstallation der Erweiterung stoppt nur den ersten.
Rund um diesen Vorfall gibt es drei häufige Missverständnisse:
- „Ein offizieller Paketname bedeutet einen offiziellen Build“: Paketname und Herausgeber waren offiziell, aber der Build stammte nicht von Anthropic. Auf Open VSX gibt es ebenfalls eine Version 2.1.312: eine saubere Version, die am 27. Oktober veröffentlicht wurde. Gleiche Versionsnummer, unterschiedliche Quelle – und unterschiedliche Sicherheit.
- „Nur 2.1.313 ist betroffen“: Auch Version 2.1.312 im Cursor-Marktplatz war manipuliert.
- „Nach Deinstallation oder Upgrade ist alles wieder sicher“: Cursor warnte ausdrücklich, dass die Deinstallation der Erweiterung allein möglicherweise nicht ausreicht, weil die Payload unabhängig laufende Persistenzskripte hinterlässt.
Claude-Code-Erweiterung: Backdoor in 5 Schritten prüfen und entfernen
Gehen Sie die folgenden fünf Schritte der Reihe nach durch. Die ersten drei dienen der Prüfung, der vierte der Bereinigung und der fünfte dem Abschluss. Zu jedem Schritt erfahren Sie, was zu tun ist und woran Sie erkennen, dass er abgeschlossen ist.
Bildunterschrift: Der Ablauf in 5 Schritten. Die Rotation der Zugangsdaten im fünften Schritt darf nicht ausgelassen werden.
① Erweiterungsversion und Herkunft prüfen. Öffnen Sie das Erweiterungspanel von Cursor, suchen Sie nach Claude Code und prüfen Sie Versionsnummer und Herausgeber. Sehen Sie anschließend im Terminal im Verzeichnis ~/.cursor/extensions/ nach (unter Windows: %USERPROFILE%\.cursor\extensions\), ob es Ordner mit anthropic.claude-code-2.1.312 oder 2.1.313 im Namen gibt. Selbst wenn Sie inzwischen eine neuere Version verwenden, deuten verbliebene Ordner alter Versionen darauf hin, dass Sie während des betroffenen Zeitraums eine solche Version installiert hatten.
② Öffentlichen svc-telemetry-Schlüssel prüfen. Führen Sie unter macOS und Linux grep -n svc-telemetry ~/.ssh/authorized_keys aus. Unter Windows müssen Sie sowohl %USERPROFILE%\.ssh\authorized_keys als auch C:\ProgramData\ssh\administrators_authorized_keys prüfen. Der Schadcode prüft, ob die Zeichenfolge svc-telemetry in der Datei vorkommt. Nur die Kommentare anzusehen, reicht daher nicht aus. Führen Sie außerdem ssh-keygen -lf ~/.ssh/authorized_keys aus, um alle Fingerabdrücke der öffentlichen Schlüssel aufzulisten, und vergleichen Sie jeden einzelnen mit dem Fingerabdruck des Angreifers: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
③ Persistenz und Tunnelprozesse prüfen. Je nach Betriebssystem sind unterschiedliche Stellen zu prüfen:
- macOS:
~/Library/LaunchAgents/com.apple.sysmond.plist,~/.config/.smt,~/.config/.smtksowie.stk_*-Dateien im temporären Verzeichnis. Der Name dieses LaunchAgents tarnt ihn als Apple-Systemkomponente, tatsächlich handelt es sich um einen benutzerspezifischen Autostart-Eintrag. - Windows: Führen Sie
schtasks /query /tn SysMonaus, um die geplante Aufgabe zu prüfen. Prüfen Sie außerdemsysmon.cmdim Autostart-Ordner sowie%USERPROFILE%\.config\smt.cmdund%TEMP%\.stk_*. - Linux: Führen Sie
crontab -laus und suchen Sie nach Einträgen mit@reboot, die auf~/.config/.smtverweisen. - Alle Plattformen: Prüfen Sie, ob bei laufenden
ssh– oderautossh-Prozessen der Parameter-R '*:0:localhost:22'vorkommt.
| Schritt | Was ist zu tun? | Abschlusskriterium |
|---|---|---|
| ① Herkunft der Erweiterung | Erweiterungspanel und ~/.cursor/extensions/ prüfen |
Keine Verzeichnisse für 2.1.312 / 2.1.313 vorhanden, aktuelle Version ≥ 2.1.314 |
| ② Öffentlicher Schlüssel | Nach svc-telemetry suchen und Fingerabdrücke vergleichen |
In beiden Arten von authorized_keys-Dateien gibt es keine Treffer |
| ③ Persistenz | plist / SysMon / Cron / Tunnelprozesse prüfen | Dateien sind nicht vorhanden, kein ssh-Prozess mit -R-Parameter läuft |
| ④ Entfernen | Offizielles Cursor-Skript ausführen und aktualisieren | Skript wird mit Exit-Code 0 beendet; erneute Prüfung von ①②③ ergibt keine Treffer |
| ⑤ Zugangsdaten | Zugangsdaten für Git, CI, Cloud und SSH sowie API-Schlüssel rotieren | Alte Zugangsdaten sind deaktiviert, Zugriffsprotokolle zeigen keine Auffälligkeiten |
④ Bei einem Treffer das offizielle Bereinigungsskript ausführen. Wenn einer der Punkte ② oder ③ zutrifft, gehen Sie nach der Cursor-Mitteilung vor. Unter macOS laden Sie cursor.com/static/security/claude-code-extension/remediate-macos.sh herunter und führen bash remediate-macos.sh als betroffener Benutzer aus – nicht als root. Unter Windows laden Sie remediate-windows.ps1 herunter, öffnen PowerShell mit „Als Administrator ausführen“ und führen powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1 aus. Laden Sie die Skripte nur von der offiziellen Cursor-Website herunter und verwenden Sie keine dubiosen „Ein-Klick-Bereinigungstools“. Das Skript entfernt die schädliche Erweiterung, Persistenzmechanismen, Tunnelprozesse und den öffentlichen Schlüssel des Angreifers. Falls noch Reste vorhanden sind, endet es mit einem Exit-Code ungleich 0. Aktualisieren Sie die Erweiterung nach der Bereinigung auf Version 2.1.314 oder höher. Stand 31. Oktober können Sie direkt Version 2.1.316 installieren.
⑤ Zugangsdaten austauschen. Dazu gehören GitHub- und GitLab-Token, CI/CD-Token, Access Keys von Cloud-Anbietern, private SSH-Schlüssel, npm- und PyPI-Token sowie der auf diesem Rechner konfigurierte API-Schlüssel für APIYI apiyi.com. Tauschen Sie die Zugangsdaten auf einem vertrauenswürdigen Rechner aus. Wenn die SSH-Logs zeigen, dass der Tunnel tatsächlich genutzt wurde, empfiehlt Phorion, den Host neu aufzusetzen. Das ist sicherer, als ihn Stück für Stück zu bereinigen.
Warum sich Angreifer bei den meisten nicht anmelden konnten – und Sie trotzdem nach der Claude-Code-Hintertür suchen sollten
Zuerst die vergleichsweise gute Nachricht: Laut einer Analyse von Phorion enthielt der Schadcode selbst Fehler. Deshalb wurde der SSH-Dienst auf den meisten Rechnern nicht erfolgreich aktiviert.
Unter macOS führte das Skript systemsetup -getremotelogin mit normalen Benutzerrechten aus. Daraufhin erschien der Hinweis, dass Administratorrechte erforderlich seien – der Exit-Code war trotzdem 0. Das Skript prüfte nur, ob die Ausgabe Off enthielt. Da das im Hinweis nicht vorkam, ging es fälschlich davon aus, dass Remote Login bereits aktiviert war, und übersprang die Aktivierung von SSH. Unter Windows wurde der PowerShell-Befehl zur Installation des OpenSSH-Servers an eine Hilfsfunktion übergeben, in der /bin/sh fest hinterlegt war. Da es /bin/sh auf einem normalen Windows-System nicht gibt, schlug dieser Schritt höchstwahrscheinlich fehl. Auch Cursor zufolge scheiterten die Aktivierung des SSH-Dienstes und der Aufbau des Tunnels, sofern Cursor nicht mit Administratorrechten gestartet wurde – was selten vorkommt.
Das heißt aber nicht, dass alles in Ordnung ist. Der öffentliche Schlüssel, das Persistenzskript und der Beacon zur Informationssammlung wurden bereits abgelegt. Als Vergleich: Das Aufbruchswerkzeug der Angreifer war defekt, weshalb viele Türen verschlossen blieben. Der Schlüssel steckt aber bereits im Schloss, und alle 60 Sekunden wird es erneut versucht.
| Kategorie | Indikator (IOC, entschärft) | Beschreibung |
|---|---|---|
| Netzwerk | 134[.]209[.]82[.]225:22，Benutzername tunnel |
Ziel des Reverse-SSH-Tunnels |
| Netzwerk | 134[.]209[.]82[.]225:8099/beacon |
Unverschlüsselter HTTP-Beacon, der Host-Informationen zurücksendet |
| Öffentlicher Schlüssel | Kommentar svc-telemetry |
Wird in authorized_keys eingetragen |
| Fingerabdruck | SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk |
Fingerabdruck des öffentlichen Schlüssels der Angreifer |
| Privater Tunnelschlüssel | SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ |
Wird als .stk_*-Datei im temporären Verzeichnis abgelegt |
| Datei | SHA-256 von extension.js beginnt mit ecb58cb2 |
Hauptdatei der schädlichen Erweiterung; vollständiger Wert in der Mitteilung von Cursor |
Bildunterschrift: Screenshot der Hash-Tabelle für schädliche VSIX-Dateien (wird während der Bearbeitung ergänzt).
In folgenden Fällen sollten Sie besonders aufmerksam sein:
- Remote Login war bereits aktiviert. Wenn Sie auf Ihrem Mac unter „Systemeinstellungen → Allgemein → Freigaben“ die entfernte Anmeldung aktiviert haben oder
Get-Service sshdunter Windows einen laufenden Dienst anzeigt, kann die Hintertür funktionieren. - Ein abgeschalteter Server bedeutet nicht, dass der Rechner sauber ist. Der Server der Angreifer ist derzeit nicht erreichbar, aber das Persistenzskript versucht weiterhin, eine Verbindung herzustellen. Solange es nicht entfernt wird, bleibt der Rechner unsicher.
- Prüfen Sie die SSH-Anmeldeprotokolle. Unter macOS können Sie
log show --predicate 'process == "sshd"' --last 7dausführen, unter Linux/var/log/auth.logprüfen und unter Windows das Protokoll OpenSSH/Operational in der Ereignisanzeige ansehen. Suchen Sie insbesondere nach erfolgreichen Authentifizierungen von127.0.0.1oder::1mit dem öffentlichen Schlüssel svc-telemetry. Schon bei einem einzigen solchen Eintrag sollten Sie davon ausgehen, dass sich jemand angemeldet hat, und erwägen, den Rechner neu aufzusetzen.
Der Schadcode sammelte außerdem Hostnamen, Benutzernamen, Systeminformationen, das Arbeitsverzeichnis, die globale Git-E-Mail-Adresse, die öffentliche IP-Adresse sowie die Namen von bis zu 40 Umgebungsvariablen. Phorions Fazit ist eindeutig: Der Bug verringerte zwar die Wahrscheinlichkeit eines unbefugten Logins, ist aber keine verlässliche Schutzmaßnahme.
Muss der APIYI-API-Schlüssel nach der Kompromittierung der Claude-Code-Erweiterung ausgetauscht werden?
Ja. Der Schadcode sammelte die Namen von Umgebungsvariablen, die KEY, TOKEN, SECRET, PASS, AWS oder GCP enthielten. Zwar las er deren Werte nicht direkt aus, doch die Angreifer wissen nun, welche Zugangsdaten auf deinem Rechner vorhanden sind. Sobald der Tunnel verfügbar ist, können sie die Werte der Umgebungsvariablen, Konfigurationsdateien und den Shell-Verlauf interaktiv auslesen. War auf dem Rechner im betroffenen Zeitraum Version 2.1.312 oder 2.1.313 installiert, solltest du den dort konfigurierten APIYI-API-Schlüssel von apiyi.com daher als „möglicherweise offengelegt“ behandeln.
Wichtig: APIYI wurde nicht angegriffen. Es besteht vielmehr das indirekte Risiko, dass der Schlüssel auf deinem eigenen Rechner ausgelesen wurde. Du solltest den Schlüssel also austauschen, musst aber nicht in Panik geraten. So gehst du vor:
| Schritt | Aktion | Überprüfung |
|---|---|---|
| 1 | Öffne die Token-Seite in der Konsole unter api.apiyi.com/token |
Die Liste der vorhandenen API-Schlüssel ist sichtbar |
| 2 | Klicke oben rechts auf „Neu“ und wähle für den API-Schlüssel von Claude Code die Gruppe ClaudeCode |
Ein neuer API-Schlüssel mit dem Präfix sk- wird erstellt |
| 3 | Setze ANTHROPIC_AUTH_TOKEN auf den neuen API-Schlüssel; ANTHROPIC_BASE_URL bleibt auf https://api.apiyi.com |
Auch env in ~/.claude/settings.json ist entsprechend aktualisiert |
| 4 | Öffne das Terminal erneut und starte Claude Code neu | Unterhaltungen und Modellaufrufe funktionieren |
| 5 | Kehre zur Token-Seite zurück und deaktiviere oder lösche den alten API-Schlüssel | Der alte API-Schlüssel ist deaktiviert |
| 6 | Prüfe die Aufrufprotokolle | Es gibt keinen Verbrauch durch ungewöhnliche Modelle oder zu ungewöhnlichen Zeiten |
Wenn deine Skripte die OpenAI-kompatible Schnittstelle nutzen, tausche auch den zu base_url="https://api.apiyi.com/v1" gehörenden API-Schlüssel im Code aus. Sende anschließend eine Testanfrage mit dem neuen Schlüssel, um zu prüfen, ob er funktioniert. Falls der alte Schlüssel noch auf anderen Rechnern oder in anderen Projekten verwendet wird, ersetze ihn überall – nicht nur auf einem Rechner.
🎯 Best Practice: Auf der Token-Seite von APIYI apiyi.com kannst du für jeden API-Schlüssel ein Guthabenlimit und eine Gültigkeitsdauer festlegen. Empfehlenswert ist ein eigener Schlüssel pro Rechner sowie die Trennung von Entwicklung und Produktion. Bei einem ähnlichen Vorfall musst du dann nur den jeweils betroffenen Schlüssel deaktivieren.
Noch einmal zur Erinnerung: Nicht nur APIYI-API-Schlüssel müssen ausgetauscht werden. Auch GitHub- und GitLab-Token, CI-Schlüssel, Access Keys von Cloud-Anbietern, private SSH-Schlüssel sowie npm- und PyPI-Token solltest du austauschen – und zwar von einem vertrauenswürdigen Rechner aus.
FAQ zur kompromittierten Claude-Code-Erweiterung
F1: Ich nutze nur den offiziellen VS Code Marketplace. Bin ich betroffen?
Dafür gibt es derzeit keine Hinweise. Die einzige nachweisbare Verbreitungsquelle ist der Cursor Marketplace. Im Microsoft Marketplace und auf Open VSX war die manipulierte Version 2.1.313 nicht verfügbar.
F2: Ich nutze nur die Claude Code CLI und keine IDE-Erweiterung. Bin ich betroffen?
Von diesem Vorfall bist du nicht betroffen. Das CLI-Paket auf npm wurde nicht manipuliert. Betroffen ist nur die VSIX-Datei der Erweiterung im Cursor Marketplace.
F3: Ich nutze Cursor, habe aber die Claude-Code-Erweiterung nicht installiert. Bin ich betroffen?
Nein. Der Schadcode wird nur ausgeführt, wenn diese Erweiterung geladen wird. Falls du dir nicht sicher bist, kannst du wie in Schritt ② beschrieben nach `svc-telemetry` suchen. Das dauert nur wenige Sekunden.
F4: Bin ich nach einem Upgrade auf 2.1.314 sicher?
Das Upgrade verhindert nur eine erneute Infektion. Bereits eingetragene öffentliche Schlüssel, Persistenzskripte und abgeflossene Informationen verschwinden dadurch nicht. Du musst weiterhin die Schritte ②③④⑤ durchführen.
F5: Sollte ich jetzt 2.1.316 installieren?
Ja. Stand 31. Oktober ist 2.1.316 die neueste Version auf GitHub Releases. Sowohl 2.1.314 als auch 2.1.316 sind sauber. Dass es dazwischen keine Version 2.1.315 gibt, ist normal.
F6: Muss ich mein System neu installieren?
Wenn nur der öffentliche Schlüssel oder die Persistenzmechanismen gefunden wurden, reicht es normalerweise aus, das offizielle Skript auszuführen und die anschließende Überprüfung abzuschließen. Zeigen die SSH-Logs jedoch, dass der Tunnel tatsächlich genutzt wurde, empfiehlt Phorion, den Host neu aufzusetzen. Denn aus dem untersuchten Schadcode lässt sich nicht ableiten, was die Angreifer nach der Anmeldung getan haben.
F7: Sind 5.000 Personen nachweislich infiziert?
Nein. Cursor spricht von „bis zu 5.000 Nutzern“. Das ist eine Schätzung der durch Downloads und automatische Updates möglicherweise Betroffenen, keine bestätigte Zahl von Infektionen. Laut Cursor werden betroffene Nutzer direkt kontaktiert.
F8: Kann mein Computer ferngesteuert werden?
Aufgrund des zuvor erwähnten Bugs wurde der SSH-Dienst auf den meisten macOS- und Windows-Rechnern nicht aktiviert. Auch der Server der Angreifer ist inzwischen offline. War die Remote-Anmeldung bei dir aber bereits aktiviert, besteht ein echtes Risiko. Ob sich jemand angemeldet hat, kannst du anhand der SSH-Logs prüfen.
F9: Kann mein APIYI-API-Schlüssel abgeflossen sein?
Die APIYI-Plattform selbst wurde nicht angegriffen. Das Risiko besteht darin, dass die Umgebungsvariablen auf deinem Rechner ausgelesen worden sein könnten. Erstelle deshalb auf api.apiyi.com/token einen neuen Schlüssel, aktualisiere deine Konfiguration und deaktiviere anschließend den alten Schlüssel.
Die wichtigsten Punkte zur kompromittierten Claude-Code-Erweiterung
- Betroffene Versionen: 2.1.312 und 2.1.313 im Cursor-Marktplatz. Andere offizielle Bezugsquellen waren nicht betroffen.
- Ausführung beim Laden: Die Erweiterung muss nicht aktiv genutzt werden. Schon beim Laden wird eine Hintertür installiert.
- Drei Spuren: Ein öffentlicher Schlüssel in
authorized_keys, ein Persistenzskript und Informationen, die über einen Beacon zurückgesendet wurden. - Bei den meisten erfolgte keine Anmeldung: Der Schadcode enthielt einen Fehler. Das ist aber kein Grund, auf eine Überprüfung zu verzichten.
- Bereinigung: Das offizielle Skript ausführen, auf Version 2.1.314 oder höher aktualisieren und den Host bei Bedarf neu aufsetzen.
- Zugangsdaten absichern: Git-, CI-, Cloud- und SSH-Zugangsdaten sowie APIYI API-Schlüssel rotieren.
Quellen
- Cursor-Sicherheitsmeldung: Betroffene Versionen, Kompromittierungsindikatoren (IOCs) und Bereinigungsskript
- Link:
cursor.com/blog/claude-code-extension-security-notice - Technische Analyse von Phorion: Analyse des Schadcodes und seines Fehlers
- Link:
phorion.io/blog/offical-claude-code-vsx-compromise - Analyse von StepSecurity: Abgleich von Registry und Versionen
- Link:
stepsecurity.io/blog/claude-code-extension-trojanized - Claude Code GitHub Releases: Offizielle Versionshistorie
- Link:
github.com/anthropics/claude-code/releases
Fazit
Das Besondere an diesem Vorfall: Die manipulierte Version verwendete den offiziellen Paketnamen. Sich am offiziellen Herausgeber zu orientieren, reicht hier also nicht aus. Empfohlen wird folgende Reihenfolge: Zuerst Version und Herkunft der Erweiterung prüfen, dann nach öffentlichen Schlüsseln und Persistenzmechanismen suchen. Bei einem Treffer das offizielle Skript ausführen und anschließend sämtliche Zugangsdaten auf einem vertrauenswürdigen Rechner erneuern.
APIYI-Nutzer können die Gelegenheit nutzen, ihre API-Schlüssel nach dem Prinzip „ein Schlüssel pro Gerät“ neu zu organisieren und dabei Gruppen, Kontingente und Gültigkeitsdauer zu überprüfen. Hinweise zur Konfiguration bietet die Dokumentation zur Token-Verwaltung auf APIYI apiyi.com.
Autor: APIYI-Technikteam
Technischer Austausch: Kontaktieren Sie uns über die Startseite von APIYI. Hinweise zur Einrichtung von Claude Code finden Sie im Dokumentationszentrum unter docs.apiyi.com.
Mit einem Versionswechsel allein ist es diesmal nicht getan: Entscheidend ist, auch Schlüssel, Persistenzmechanismen und Zugangsdaten zu überprüfen.
