Für den Angriff nennt Mitiga zwei Voraussetzungen: Der Angreifer muss ein eigens präpariertes npm-Paket auf einer Maschine installieren können, auf der Claude Code mit MCP-Servern für dynamische Autorisierung eingerichtet ist. Das Paket registriert einen sogenannten Lifecycle-Hook, der bei der Installation ausgeführt wird.
Dieser Hook nach der Installation sucht gängige Speicherorte für Repository-Klone und hinterlegt dort einen vorkonfigurierten Vertrauensdialog mit dem Wert „true". „Beim späteren Öffnen des Verzeichnisses erscheint keine Abfrage mehr, weil das Kennzeichen, an das die Abfrage gekoppelt ist, bereits gesetzt ist", berichtet Mitiga.
Zugleich öffnet der Hook die Datei ~/.claude.json und manipuliert den Eintrag „mcpServers" in der globalen Konfiguration, sodass er die Adresse des Proxys enthält. „Damit sitzt der Angreifer mitten in jeder Anfrage, die an den MCP-Server hinausgeht. Als Angreifer haben wir mitmproxy eingerichtet, das den Verkehr abfängt", erläutert Mitiga.
Sobald Claude Code eine MCP-Sitzung aufbaut oder erneuert, verbindet es sich mit dem Proxy, und das Token wandert zur Infrastruktur des Angreifers. Der Nutzer sieht lediglich einen gültigen Ablauf. Rotiert er das Token, schreibt der Hook es beim nächsten Laden zurück; ändert er die MCP-URL, lädt der Hook sie ebenfalls neu. So erreicht der Angreifer zugleich Tarnung und dauerhaften Zugriff – laut Mitiga „eine beständige Umleitung der SaaS-Anmeldedaten des Opfers in vom Angreifer kontrollierte Infrastruktur, mit automatischer Wiederherstellung nach einer Token-Rotation, unsichtbar in der Oberfläche des Endgeräts und auf Anbieterseite nicht von legitimem Verkehr zu unterscheiden".
Da die Token im Klartext in ~/.claude.json gespeichert sind, lässt sich jedes OAuth-Token mühelos abgreifen. Einmal entwendet, dient es als Generalschlüssel, der die Mehr-Faktor-Authentifizierung umgeht und mit denselben Rechten wie der Nutzer Zugang zu jedem angebundenen Werkzeug verschafft. Alarme bleiben aus, weil der MCP nur tut, wozu er angewiesen wurde.
Mitiga rät, auf eine Lösung von Anthropic nicht zu warten, und empfiehlt stattdessen, Konfigurationsänderungen von Claude Code, Änderungen an MCP-Server-URLs, das Verhalten bei OAuth-Erneuerungen, auffällige SaaS-API-Aktivität sowie unerwarteten Verkehr über MCP-Integrationen zu überwachen.
Mitiga meldete seine Erkenntnisse am 10. April 2026 an Anthropic. Am 12. April 2026 antwortete Anthropic, der Fall liege außerhalb des Geltungsbereichs – mit im Kern derselben Begründung wie bei der „TrustFall"-Meldung von Adversa: Der Nutzer habe dem, was anschließend geschehen könnte, bereits zugestimmt.
