Claude Code in Cursor manipuliert: Warum ein Update nicht reicht

Ein vertrauter Name, ein gewöhnliches Update und eine zusätzliche Hintertür: Am 29. Oktober 2026 war im Erweiterungsmarktplatz von Cursor eine manipulierte Claude-Code-Version verfügbar. Sie sollte Entwicklern unbemerkt einen fremden SSH-Zugang auf den Rechner setzen. Für betroffene Unternehmen endet die Arbeit deshalb nicht mit dem nächsten Update: Entscheidend ist, was auf dem Arbeitsplatz ausgeführt wurde und welche Zugänge von dort erreichbar waren.

Der Fall ist ernst. Er ist aber enger begrenzt, als manche ersten Schlagzeilen vermuten lassen: Bestätigt ist ein manipuliertes Paket im Cursor-Marketplace, kein allgemeiner Einbruch bei Anthropic.

Das Wichtigste

• Prüft Erweiterung, Version und Bezugsquelle zusammen: Im Mittelpunkt steht anthropic.claude-code in Version 2.1.313 aus dem Cursor-Marketplace.
• Das verdächtige Paket konnte beim Laden der Erweiterung aktiv werden. Ein Chat mit Claude war dafür nicht nötig.
• Ein fehlgeschlagener SSH-Zugang macht den Rechner nicht automatisch sauber. Schlüssel und Autostart-Dateien können trotzdem zurückbleiben.
• Trennt die Untersuchung des Arbeitsplatzes von der Wiederfreigabe seiner Zugänge. Eine bereinigte Erweiterung beweist noch keinen vertrauenswürdigen Rechner.

Recherchestand: 30. Oktober 2026, 15:33 Uhr MEZ. Wir haben Herstellerhinweis, aktualisierte Forscherberichte und Microsoft-Dokumentation abgeglichen. Dies ist eine redaktionelle Quellenrecherche; wir haben das Schadpaket nicht selbst ausgeführt oder forensisch untersucht. Die Grafiken sind eigene schematische Darstellungen.

Was Cursor bestätigt — und was offenbleibt

Im Sicherheitshinweis von Cursor wird das Verteilfenster mit dem 29. Oktober, ungefähr 2:27 bis 13:35 Uhr Pacific Time, angegeben. Das entspricht 10:27 bis 21:35 Uhr MEZ. Cursor nennt höchstens 5.000 betroffene Nutzer. Das ist eine Anbieterangabe zur Reichweite, keine Zahl nachgewiesener erfolgreicher Fernzugriffe.

Laut Anbieter wurden Paket und Verteilung gesperrt, der Marktplatz überprüft und nach Schlüsselrotation neu aufgebaut. Der Angreiferserver sei gemeinsam mit seinem Hosting-Anbieter abgeschaltet worden. Wie das manipulierte Paket in die Verteilung gelangte, ist aus den geprüften Quellen nicht abschließend geklärt.

Warum wir nicht pauschal Open VSX als Ursprung nennen

Frühe Berichte ordneten das Paket Open VSX zu. OpenSourceMalware hat diese Zuordnung ausdrücklich korrigiert: Ursprung sei der Cursor-Marketplace. Auch The Hacker News weist auf die Korrektur hin.

Andere technische Berichte verwenden noch die frühere Zuordnung. Wir übernehmen daraus technische Befunde nur als solche; ihre Registry-Aussage ist kein zusätzlicher Beleg für eine breitere Verteilung. Eine nicht mehr verfügbare Versionsnummer allein beweist ebenfalls keine Manipulation.

Für npm, Open VSX und Microsofts Visual Studio Marketplace liegt in den hier abgeglichenen aktuellen Quellen kein entsprechender Kompromittierungsnachweis vor. Daraus folgt keine allgemeine Unbedenklichkeitsbescheinigung für jede Installation: Herkunft und Paket müssen zusammenpassen.

Wie aus einer Editor-Erweiterung ein Fernzugang werden sollte

Die technische Analyse von OpenSourceMalware beschreibt einen vorangestellten Loader in extension.js. Er läuft vor dem regulären Erweiterungscode. Das erwartete Programm kann dadurch weiterhin funktionieren, während der zusätzliche Code bereits arbeitet.

Die Angriffskette hat drei für die Reaktion wichtige Teile:

1. Zugang vorbereiten: Ein fremder öffentlicher SSH-Schlüssel wird in die Benutzerkonfiguration eingetragen.
2. Erreichbarkeit herstellen: Ein ausgehender Reverse-SSH-Tunnel soll Verbindungen zum lokalen SSH-Dienst weiterleiten.
3. Wiederkommen ermöglichen: Betriebssystemspezifische Autostart-Mechanismen sollen den Tunnel erneut starten.

SSH ist ein legitimes Verfahren für verschlüsselte Fernzugriffe. Ein Reverse-Tunnel beginnt vom betroffenen Rechner aus. Deshalb beantwortet die Frage „Haben wir eingehende Verbindungen aus dem Internet blockiert?“ nicht allein, ob dieser Zugangsweg möglich war. Zusätzlich zählen ausgehende Verbindungen, der lokale Dienst und die Anmeldung daran.

Die Forscher unterscheiden außerdem Namen und Inhalte von Umgebungsvariablen: Der untersuchte erste Beacon übermittelt unter anderem passende Variablennamen, nicht unmittelbar deren Werte. „Alle API-Schlüssel wurden gestohlen“ wäre deshalb eine unbelegte Zuspitzung. Erfolgreicher interaktiver Zugriff könnte allerdings weitere Daten erreichbar machen. Ob es dazu kam, muss die Untersuchung des jeweiligen Hosts zeigen.

Weshalb fehlende Administratorrechte keine Entwarnung sind

Phorion erläutert einen Fehler im macOS-Zweig: Die Prüfung des Remote-Login-Status kann ohne Administratorrechte eine Fehlermeldung liefern, die der Schadcode falsch behandelt. Ist SSH noch nicht aktiv, kann dadurch die vorgesehene Aktivierung ausbleiben. Ein bereits laufender Dienst verändert die Ausgangslage.

Das sind unterschiedliche Befunde: Schadcode ausgeführt, Persistenz angelegt, Tunnel verbunden und erfolgreich angemeldet dürfen im Incident-Bericht nicht zu einem einzigen Ja/Nein-Feld zusammenfallen. Ein gescheiterter Teil der Kette schließt die anderen nicht aus. Ebenso wenig lässt sich aus der bloßen Anwesenheit eines Indikators jede spätere Handlung des Angreifers ableiten.

Was IT und Security jetzt gemeinsam prüfen sollten

Die folgenden Schritte sind unsere Arbeitsstruktur für die interne Reaktion. Konkrete Bereinigungsdetails sollten mit dem jeweils aktuellen Herstellerhinweis und eurem Incident-Response-Verfahren abgeglichen werden.

1. Eine belastbare Liste betroffener Arbeitsplätze erstellen

Sammelt Editor, Erweiterungs-ID, installierte beziehungsweise zuvor ausgeführte Version, Plattform und Bezugsquelle. Prüft auch verwaltete Remote-Entwicklungsumgebungen, soweit dort die Erweiterung tatsächlich ausgeführt wurde. „Wir benutzen Claude“ ist als Suchkriterium zu ungenau.

Haltet für jeden Arbeitsplatz fest, worauf die Einordnung beruht: Installationshistorie, gesichertes Paket, Endpoint-Meldung oder nur die Erinnerung eines Nutzers. Ein nachträglich aktualisierter Versionsstand beantwortet nicht, welche Version gestern lief.

2. Hinweise sichern, bevor ihr sie entfernt

Der Herstellerhinweis enthält konkrete Indikatoren und Bereinigungshilfen. Zu den Suchansätzen gehören der SSH-Schlüsselkommentar svc-telemetry, die Adresse 134[.]209[.]82[.]225, versteckte Konfigurationsdateien und ungewöhnliche Autostarts. Einzelne Namen können mehrdeutig sein; gleicht Schlüssel, Pfade und Zeitpunkte miteinander ab.

Sichert relevante Dateien und Protokolle nach eurem Verfahren. Ein negativer Einzeltest ist keine forensische Freigabe: Dateien können fehlen, verändert oder bereits entfernt worden sein. Wir übernehmen deshalb keine pauschale „nicht betroffen“-Aussage allein aus einem erfolglosen Suchbefehl.

3. Den möglichen Zugang zu weiteren Systemen eingrenzen

Fragt für jeden betroffenen Benutzer: Welche Repositories, Cloud-Konten, Paketregistries und administrativen Systeme waren erreichbar? Unterscheidet gespeicherte Zugangsdaten, aktive Sitzungen und Berechtigungen, die erst über weitere Systeme nutzbar würden.

Diese Liste entscheidet, welche Verantwortlichen hinzukommen und welche Zugänge gesperrt oder erneuert werden müssen. Die Möglichkeit eines Zugriffs ist noch kein Beleg für Datenabfluss; sie ist ein begründeter Untersuchungsauftrag.

4. Wiederherstellung und Wiederfreigabe dokumentieren

Legt fest, wer über Isolation, Bereinigung oder Neuaufsetzen entscheidet und welche Nachweise für die Wiederfreigabe nötig sind. Erneuert betroffene Zugangsdaten von einem vertrauenswürdigen System aus. Dokumentiert neben dem Ergebnis auch offene Fragen und die Grenzen eurer Protokolle.

„Die Erweiterung ist aktualisiert“ darf nicht das einzige Abschlusskriterium sein. Besser sind getrennte Entscheidungen für Arbeitsplatz, Identitäten und möglicherweise erreichbare Systeme. So bleibt sichtbar, wenn der Rechner wieder betriebsbereit ist, eine Cloud-Sitzung aber noch geprüft werden muss.

Was Unternehmen aus dem Fall für ihre Software-Lieferkette lernen können

Die Freigabe eines KI-Werkzeugs beantwortet oft Fragen zu Vertragsbedingungen, Datenverarbeitung und erlaubten Anwendungsfällen. Dieser Vorfall lenkt den Blick auf eine weitere Ebene: Welcher ausführbare Code kommt über welchen Update-Kanal auf den Arbeitsplatz?

Microsoft dokumentiert, dass der Extension Host dieselben Rechte wie VS Code besitzt. Erweiterungen können damit beispielsweise Dateien verändern und Prozesse starten. Diese allgemeine Architektur erklärt den Handlungsspielraum; sie ist kein Nachweis einer Betroffenheit des Microsoft-Marketplace in diesem Vorfall.

Für eure nächste Überprüfung schlagen wir diese konkrete Entscheidungstabelle vor:

Bei VS Code lassen sich zugelassene Erweiterungen und Versionen zentral steuern. Microsoft beschreibt aber auch Grenzen: Bei lokal gelieferten VSIX-Dateien prüfen solche Regeln deklarierte Kennungen; sie beweisen nicht die Herkunft und begrenzen nicht automatisch die Laufzeitrechte. Prüft für jeden verwendeten Editor dessen eigene Durchsetzung, statt eine Konfiguration ungeprüft auf alle Ableger zu übertragen.

Ein mögliches internes Ergebnis wäre: Entwicklung bleibt arbeitsfähig, aber Installationsquellen sind festgelegt, Produktionszugänge werden getrennt behandelt und es gibt einen benannten Verantwortlichen für Erweiterungswarnungen. Das ist hilfreicher als ein pauschales KI-Verbot oder eine Freigabe ohne Zuständigkeit.

Der Unterschied zum fehlgeleiteten KI-Agenten

In unserem Artikel zum AISI-Lieferkettenversuch ging es um einen Agenten, der seinen Auftrag überschritt. Hier geht es um manipulierten Erweiterungscode. Ein sorgfältig formulierter Prompt hätte den vorangestellten Loader nicht kontrolliert.

Für Unternehmen verbinden sich beide Themen über Zugriffe, Überwachung und Verantwortung. Die Ursachen und wirksamen Schutzmaßnahmen müssen trotzdem getrennt bleiben. Wer jedes Problem als „KI halluziniert“ behandelt, untersucht womöglich das Modell, obwohl der Einstieg in der Softwareverteilung lag.

In Kopexa könnt ihr die organisatorische Nachbereitung mit Risiken, Maßnahmen, Zuständigkeiten und Nachweisen verbinden. Das ersetzt weder Endpoint-Erkennung noch forensische Untersuchung. Es hilft, aus dem technischen Befund nachvollziehbare Arbeit zu machen: Welche Maßnahme ist offen, wer entscheidet, und womit wird die Umsetzung belegt? Ein konkreter Ausgangspunkt für eine Kopexa-Demo ist euer Ablauf vom Sicherheitsvorfall bis zur freigegebenen Nachbereitung.

Welche Fragen noch keine gesicherte Antwort haben

Aus den geprüften Quellen lassen sich weder die vollständige Einbringungsmethode noch erfolgreiche Zugriffe auf sämtliche betroffenen Rechner oder ein umfassender Datenabfluss ableiten. Eine abgeschaltete Infrastruktur und eine entfernte Version sind wichtige Reaktionen, ersetzen aber nicht die Untersuchung bereits ausgeführter Pakete.

Unser Prüfmaßstab für weitere Updates bleibt deshalb: Welche neue Aussage ist durch welchen Befund belegt, und ändert sie die Betroffenheit oder die erforderlichen Maßnahmen? Neue Originalmeldungen können diese Einordnung verändern.