Am 29. Oktober 2026 war rund elf Stunden lang eine manipulierte Version der offiziellen Claude Code Extension im Cursor Extension Marketplace verfügbar (Versionen 2.1.312 und 2.1.313). Die manipulierte Version sollte eine persistente SSH-Backdoor auf dem Rechner einrichten. Cursor entdeckte den Vorfall, schaltete den Marketplace vorübergehend komplett ab und hat ihn nach Audit und Key-Rotation wieder geöffnet.
Was hat der Schadcode gemacht?
Sobald die Extension beim Editor-Start geladen wurde, versuchte der Schadcode:
- SSH-Backdoor: Der Public-Key des Angreifers wurde mit dem harmlos wirkenden Label
svc-telemetryin~/.ssh/authorized_keysangehängt, und ein Reverse-SSH-Tunnel zum Angreifer-Server wurde eingerichtet - Datenexfiltration: Hostname, Username, OS, Home-Verzeichnis, Git-E-Mail, öffentliche IP und die Namen (nicht die Werte) von bis zu 40 Umgebungsvariablen mit KEY/TOKEN/SECRET/PASS/AWS/GCP. Damit wusste der Angreifer, welche Cloud-Credentials wo liegen.
- Beacon: Die Host-Daten wurden über unverschlüsseltes HTTP an den Angreifer gemeldet.
- Persistenz: Die Backdoor wurde über eine LaunchAgent (MacOS) bzw. einen scheduled task + startup script (Windows), die die Backdoor bei Entfernen wiederherstellen sollten abgesichert.
Glück im Unglück: Um den lokalen SSH-Dienst zu starten benötigt man Admin Rechte, die die Extension auf fast allen Maschinen nicht hatte. Zusätzlich enthielt der Schadcode einen Bug. Dieser Schritt ist dementsprechend gescheitert. Die Platzierung des SSH-Keys und die Datenexfiltration liefen aber trotzdem.
Wer ist betroffen?
- Maximal 5.000 Entwickler haben die Schadversion installiert; Cursor kontaktierte diese direkt.
- Der Zugriff erfolgte mit hoher Wahrscheinlichkeit nur auf den Cursor Marketplace. Claude Code Repo, npm und der Microsoft VS Code Marketplace sind nicht betroffen, Anthropic betont, dass seine eigenen Systeme sauber sind.
- Wäre das Claude Code Repo selbst kompromittiert worden, wären potenziell deutlich mehr Entwickler und indirekt noch deutlich mehr Endkunden betroffen gewesen.
Wie kann ich das fixen?
Die Behebung ist hier Beschrieben: https://cursor.com/blog/claude-code-extension-security-notice
Kann man solchen Angriffen mit VM oder docker Sandboxen begegnen?
Kurze Antwort: Ja.
Das Kernproblem dieser Art von Angriff: Ein AI-Coding-Assistent (bzw. die IDE und seine Coding Agent Extension) läuft oft mit den vollen Rechten des Benutzers auf einer Maschine, auf der in vielen Fällen auch Credentials liegen (z.B. AWS_ACCESS_KEYS). Die Sandboxing Mechanismen des Agents, normalerweise sind das OS basierte mechanismen, sind in der Regel mit wenig Aufwand überwunden (oder Entwickler klicken Zugriffsbestätigungen aus Gewohnheit weg). Besser ist das Sandboxing mithilfe von Virtuellen Maschinen oder Docker.
Der Angiffsvektor ist nicht nur die Supply Chain: Prompt Injection, schädliche Anweisungen aus gelesenen Dateien oder Repos (gitspawn, https://www.manifold.security/blog/ai-coding-agents-git-hijack), ein Agent, der „falsche“ Befehle ausführt, all das trifft dieselbe Maschine mit denselben Secrets.
Die eine Maßnahme ist die Sandbox:
- Den Agent- und IDE-Betrieb in einer Sandbox (Docker/VM) laufen lassen, in Docker (z.B. https://code.claude.com/docs/en/devcontainer) oder einer VM (z.B. via https://microsandbox.dev). Auch die Nutzung von https://guix.gnu.org macht viele Möglichkeiten auf (nicht nur für AI Sandboxing: https://200ok.ch/posts/2025-05-23_sandboxing_ai_tools:_how_guix_containers_keep_your_host_safe_while_empowering_llms.html, https://guix.gnu.org/cookbook/en/html_node/Guix-Containers.html). Lösungen wie Microsandbox ermöglichen dabei einen schnellen start der VM (> 100ms, zuzüglich Coding Agent oder IDE).
- Ohne irgendwelche Credentials in der Sandbox. Wenn der Agent gar keine API-Keys, Git-Tokens oder DB-Passwörter in seiner Umgebung hat, kann ein Angreifer auch nichts exfiltrieren.
- Nötige Zugangsdaten außerhalb der Sandbox bereitstellen, z. B. über Proxies wie Llama Swap oder LiteLLM: Der Agent spricht einen lokalen Proxy an, der die eigentlichen Secrets für den Zugriff auf das LLM außerhalb der Sandbox hält und nur die benötigten Calls weiterleitet.
- Zugriffe beschränken: Manche Lösungen bieten auch die Möglichkeit Netzwerkzugriffe auf bestimmte Domains zu beschränken. Whitelisting is hier generell der bessere Ansatz. Auch ein .ssh Verzeichnis hält man aus der VM herraus und verhindert den Zugriff.
- Cloud: Auch die Nutzung von VMs in der Cloud ist möglich. Hier sind viele Unterschiedliche Ansätze denkbar.
Der potenzielle Blast Radius der Angriffsvektoren wird mit richtigem Sandboxing deutlich reduziert, während der Aufwand überschaubar bleibt. Sandboxing ist in einem Agentic Workflow kein „nice to have“, sondern eine wichtige Verteidigungslinie. Nutzt man einen Kommandozeilen Coding Agent wie OpenCode (oder die Kommandozeilenvariante von Claude Clode) und man möchte die VM leichtgewichtig halten, kann man auch die IDE aus der VM herrauslösen, shared das Projektverzeichnis und benötigt dann gar keine Secrets in der VM. Eine solche Lösung schützt natürlich nicht vor anderen kompromitierten Extensions.
Kann eine Sandbox ansonsten jeden Angriff verhindern? Mit Sicherheit nicht. Aber eine Sandbox kann den Aufwand, den ein Angreifer für einen erfolgreichen Angriff betreiben muss, signifikant erhöhen.
Fazit
Der Claude Code / Cursor-Hack zeigt, dass auch die Supply Chain von AI-Development-Tools als Angriffsziel attraktiv ist. Gleichzeitig gibt es Konzepte, die potentielle Auswirkungen eines Angriffs erheblich senken können und mit nur wenig Aufwand eingerichtet werden können.
Haben Sie Fragen oder benötigen Sie Unterstützung dabei Ihren Entwicklungsprozess abzusichern? Dann melden Sie sich gerne bei Felix Eckhardt oder Mark Holst.
